11. SWIFT gpi

11.1 gpi Maintenances

This section contains all the maintenances pertaining to gpi. All the gpi Maintenances are applicable for the payment types - Cross Border/ RTGS.

Following are the required maintenances for gpi:

l SWIFT gpi Directory Detailed (PMDGPIDR)

l SWIFT gpi Static Preferences (PXDGPIST)

l SWIFT gpi Host Preferences Detailed (PXDGPIPF)

l Outbound gpi Payment Receiver Agreement (PXDSROAG)

l Inbound gpi Payment Sender Agreement (PXDSRIAG)

l Flat File gpi Directory Upload Detailed (PMDGPIUP)

l SWIFT gpi Confirmation Reject Code Mapping (PXDGPIRM)

l SWIFT gpi/Universal Confirmation - Manual Generation (PXDGPIMC)

l SWIFT gLowValue Payment Host Preferences (PXDGPSPF)

l Customer Preferences Detailed (PMDFLPRF) - Refer to Payments Core User manual.

11.1.1 SWIFT gpi Static Preferences

This is a factory shipped data listing gpi Message Type, gpi service identification mapping, gCCT/ gCOV status codes and reason codes and can be modified by the user.

You can invoke the ‘SWIFT gpi Static Preferences’ screen by typing ‘PXDGPIST’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button. Click ‘New’ button on the Application toolbar.

Actions allowed in this screen are:

l Save

l Enter Query

l Unlock

l Authorize

Following are the grids available in this screen:

gpi Message Type and Service ID Mapping

All the fields and data in this grid are factory shipped. You can change the values in the ‘Service ID’ field only.

gpi Confirmation Status Code

All the fields and data in this grid are factory shipped. You can change the values in the ‘gCCT/gCOV Confirmation Status Code’ field only.

gCCT Reason Code

All the fields and data in this grid are factory shipped. You can change the values in the ‘gCCT Reason Code’ field only.

gCOV Reason Code

All the fields and data in this grid are factory shipped. You can change the values in the ‘gCOV Reason Code’ field only.

gSRP Response Code

All the fields and data in this grid are factory shipped. You can change the values in the ‘Response Code’ field only.

gSRP Request Reason Code

All the fields and data in this grid are factory shipped. You can add/remove Reason codes and Description.

gSRP Response Reason Code for Interim

All the fields and data in this grid are factory shipped. You can add/remove Reason codes and Description

gSRP Response Reason Code for Reject

All the fields and data in this grid are factory shipped. You can add/remove Reason codes and Description

 

gpi Reject Reason Codes

All the fields and data in this grid are factory shipped. You can add/remove Reason codes and Description.

 

11.1.2 Outbound gpi Payment Receiver Agreement

You can maintain the Outbound payment -receiver agreement through this screen.

You can invoke ‘Outbound gpi Payment Receiver Agreement’ screen by typing ‘PXDSROAG’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Actions allowed in this screen are:

l New

l Save

l Copy

l Enter Query

l Unlock

l Delete

l Authorize

You can specify the following details:

Host Code

System defaults the Host code of the selected branch on clicking ‘New’ button.

Host Code Description

System defaults the Description of the host Code displayed.

gpi Participant ID

Select the gpi Participant ID from the list of values. All valid gpi Participant IDs from the gpi directory are listed here.

Participant Name

System defaults the Participant Name on selecting the gpi Participant ID.

Transaction Currency

System defaults the Transaction Currency on selecting the gpi Participant ID.

gpi Transfer Type

Select the Transfer Types from the drop-down values. The values are:

l gCCT

l gCOV

Note

gCCT represents MT 103 and gCOV represents MT 202COV/205COV

 

gpi OUT Details

gpi Receiver Charge

Specify the Receiver Charge. This is an input field and is picked up for 71G, in case of ‘OUR’ Charges.

gpi Cutoff Days

Specify the Cutoff days. This indicates number of Settlement days required for outbound payments.

Note

Cutoff days processing calculation logic is same as SWIFT payments (Outbound BIC Cut­off Detailed (PXDCYCOF))

 

gpi OUT Cutoff (HH:MM)

Specify the OUT Cutoff time. This is an user input field. Hour Field accepts value between ‘0’ and ‘23’. Minutes field accepts value between ‘0’ and ‘59’.This is maintained in Host Zone.

If this is breached , then Outbound gpi payments will move to Network Cutoff Queue. If this maintenance is not available, then cutoff time at gpi directory is checked.

Earliest Release Days

Specify the Earliest Release Days for releasing the message.

Earliest Release Time (HR)

Specify the Earliest Release Time in Hour.

Earliest Release Time (Min)

Specify the Earliest Release Time in Minutes.

11.1.2.1 Outbound gpi Payment Receiver Agreement Summary

You can invoke ‘Outbound gpi Payment Receiver Agreement Summary’ screen by typing ‘PXSSROAG’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Authorization Status

l Record Status

l gpi Transfer Type

l Host Code

l gpi Participant ID

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

Double click a record or click the ‘Details’ button after selecting a record to view the detailed screen.

11.1.3 Inbound gpi Payment Sender Agreement

You can maintain the Inbound payment -sender agreement through this screen.

You can invoke ‘Inbound gpi Payment Sender Agreement’ screen by typing ‘PXDSRIAG’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Actions allowed in this screen are:

l New

l Save

l Copy

l Enter Query

l Unlock

l Delete

l Authorize

You can specify the following details:

Host Code

System defaults the Host code of the selected branch on clicking ‘New’ button.

Host Code Description

System defaults the Description of the host Code displayed.

gpi Participant ID

Select the gpi Participant ID from the list of values. All valid gpi Participant IDs from the gpi directory are listed here.

Participant Name

System defaults the Participant Name on selecting the gpi Participant ID.

Transaction Currency

System defaults the Transaction Currency on selecting the gpi Participant ID.

gpi Transfer Type

Select the Transfer Types from the dropdown values. The values are:

l gCCT

l gCOV

Note

gCCT represents MT 103 and gCOV represents MT 202COV/205COV.

 

gpi Details

gpi Cutoff Days

Specify the Cutoff days. This indicates number of Settlement days required for inbound payments.

Note

Cutoff days processing calculation logic is same as SWIFT payments (Inbound BIC Cutoff Detailed (PXDINCOF))

 

gpi IN Cutoff (HH:MM)

Specify the IN Cutoff time. This is an user input field. Hour Field accepts value between ‘0’ and ‘23’. Minutes field accepts value between ‘0’ and ‘59’.This is maintained in Host Zone.

If this is breached, then inbound gpi payments will move to Network Cutoff Queue. If this maintenance is not available, then cutoff time at gpi directory for Receiver BIC is referred.

11.1.3.1 Inbound gpi Payment Sender Agreement Summary

You can invoke ’Inbound gpi Payment Sender Agreement Summary’ screen by typing ‘PXSSRIAG’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Authorization Status

l Record Status

l gpi Transfer Type

l gpi Participant ID

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

Double click a record or click the ‘Details’ button after selecting a record to view the detailed screen.

11.1.4 SWIFT gpi Host Preferences

You can maintain the Host preferences for SWIFT gpi in this screen.

You can invoke ‘SWIFT gpi Host Preferences’ screen by typing ‘PXDGPIPF’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Actions allowed in this screen are:

l New

l Save

l Copy

l Enter Query

l Unlock

l Delete

l Authorize

You can specify the following details:

Host Code

gpi Preferences are maintained at Host level. System defaults the host code of the logged in user.

Host Code Description

System defaults the description of the host Code displayed.

gpi/Universal Confirmation Message Generation Preference

Generation Mode

Select the gpi/Universal confirmation message generation preference mode as follows:

l Automatic

l Manual

gpi Tracker BIC

Specify the gpi Tracker BIC. This field supports Alpha Numeric values and character length supported is between 8 and 11. Else error is thrown.

gCCT Enabled

This flag, when checked, indicates that it is a bank preference for processing SWIFT payments (Outbound and Inbound) as gpi payments.

System applies gpi payments processor logic, only when the flag is checked. If not checked, it is processed as normal SWIFT payments.

This flag is unchecked by default.

gFIT Enabled

This flag is to capture whether the branch BIC is participating in the SWIFT gpi gFIT optional service or not.

Tracker Interaction Type

gpi Confirmation

Select the Interactions types from the drop-down values. The options listed are - ‘FIN Based/ API Based’.

gSRP Request

Select the Request Message types from the drop-down values. The options listed are - ‘MT 192/ MT 199/ API Based’.

gSRP Response

Select the Response Message types from the drop-down values. The options listed are - ‘MT 196/ MT 199/ API Based’.

gSRP Recall-Response Days

Recall Days

Specify the number of days with in which the recall request should be initiated. This field accepts only Numerical values in the range - 1 to 999.

Response Days

Specify the number of days with in which the Response request to be received. This field accepts only Numerical values in the range - 1 to 99.

11.1.4.1 SWIFT gpi Host Preferences Summary

You can invoke ‘SWIFT gpi Host Preferences Summary’ screen by typing ‘PXSGPIPF’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Authorization Status

l Record Status

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

Double click a record or click the ‘Details’ button after selecting a record to view the detailed screen.

11.1.5 SWIFT gpi Directory

You can invoke the ‘SWIFT gpi Directory Maintenance’ screen by typing ‘PMDGPIDR’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button. You can query the records uploaded.

You can specify the following fields:

Participant ID

Participant's routing ID, reachable for receiving gpi payments is captured in this field.

Participant Name

Participant’s Institution’s name is displayed in this field.

ID Type

System defaults the ID Type for the Participant ID entered

Cutoff Day

Specify the Cuttoff Day. It can be empty denoting same day payment or D-n. "D-n" indicates that the participant's listed CUT-OFF TIME is n business day earlier.

Cutoff Day is used for “illiquid” currencies, where the participant cannot obtain settlement of the payment on the same day or next day because there is no spot market for buying this currency.

Platform

Specify the Platform that distinguishes the gpi directory from other directories in the SWIFTRef Reach Plus distribution. You can input the value of service platform. The possible values will be GPI and GPI Case.

Local Time Zone

Specify the Local Time Zone. If the time zone is present in gpi directory, system will pick up the given cutoff time 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.

Service Identification

Specify the Service Identification. It refers to the value of field 111 in block 3 of the gpi MT103 message generated (Eg: You can input value as 001, 004, 005 and 006).

Act As Intermediary

If this check box is checked, the participant acts as the gpi Intermediary Agent for gpi payments in a given currency and over a given REACHABLE THROUGH channel.

Service Name

Specify the Service Name. It denotes to which gpi service (gpi 001/ gpi 004 / gpi 009) the Participant ID is a gpi member.

Delegated To

The BIC must take the action of forwarding the payment or updating the tracker on behalf of the participant, ID. It is a valid BIC of 8 characters. It applies to gpi services 001, 004, and 005.

Maximum Amount

This field contains the maximum amount allowed for a gpi Instant transaction in a given currency. Only applicable to Service ID 005-gpi Instant.

Reachable Through

Specify the channel through which the participant is reachable for gpi payment instructions for one of its gpi currencies. If the Channel type is Intermediary, then reachable through will be another gpi participant ID through which the current participant ID is eligible to do gpi transactions.

Allowed values are:

l Another gpi participant ID (BIC Code)

l D-C (Direct - Cover)

l TGT / EBA

Country Code

Specify the participant's two-character ISO country code.

Channel Type

Specify the type of the REACHABLE THROUGH channel.

Currency Code

Specify the valid Currency Code from the list of values.

The three-character ISO currency, accepted in field 32A of Inbound gpi MT 103 payments by the PARTICIPANT ID, or by the gpi intermediary (if any) where the participant can be reached for this currency.

Cutoff Time

System defaults the Cutoff Time for the Participant ID entered. This indicates the Participant's public gpi cut-off time for gpi payments in this currency.

Start of Day

Specify the Start of Day.

Start Date

Specify the Stop Date.

Stop Date

Specify the Stop Date.

11.1.5.1 Viewing SWIFT gpi Directory Summary

You can invoke “SWIFT gpi Directory Summary” screen by typing ‘PMSGPIDR’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Authorization Status

l Record Status

l Participant ID

l Currency Code

l Channel Type

l Reachable Through

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

l Authorization Status

l Record Status

l Participant ID

l Participant Name

l ID Type

l Platform

l Service Identification

l Service Name

l Country Code

l Currency Code

l Channel Type

l Reachable Through

l Cutoff Day

l Local Time Zone

Double click a record or click the ‘Details’ button after selecting a record to view the detailed screen.

11.1.6 Flat File gpi Directory Upload

User can upload gpi file through this screen by specifying a valid file path and file name.

You can invoke the ‘Flat File gpi Directory Upload’ screen by typing ‘PMDGPIUP’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button. Click ’New’ button on the Application toolbar.

You can specify the following fields:

File Name

Specify the name of the file to be uploaded

File Path

Specify the path in the server where the file is uploaded.

Click on upload button to Upload the file to the specified File Path.

 

11.1.7 SWIFT gpi Confirmation Reject Code Mapping

You can capture the reject reason code to be populated in gpi confirmations when auto cancellation is triggered due to reject responses from external systems.

You can invoke ‘SWIFT gpi Confirmation Reject Code Mapping’ screen by typing ‘PXDGPIRM’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can specify the following details:

Host Code

System defaults the Host code of the selected branch on clicking ‘New’ button.

Host Code Description

System defaults the Description of the Host Code displayed.

Network Code

Specify the Network Code from the list of values. Lists all valid (Open / Authorized) Cross Border / RTGS & Fedwire.

Network Code Description

System defaults the Description of the Network Code displayed.

Network Type Description

System defaults the Network Type Description of the Network Code displayed.

Reject Reason

Specify the Reject Reason from the list of values. List all the gpi Confirmation Reject reason codes from SWIFT gpi Static Preferences Detailed (PXDGPIST).

Reject Reason Description

System defaults the Description of the Reject Reason displayed.

Error Code Linkage

Error Type

This field displays description of the selected Error Code.

Error Code

Specify the Error Code from the list of values. Lists all the valid (Open/Authorized) Error codes defined in the 'User Defined Error Codes' maintenance (PMDERRCD) for the host code.

Error Description

This field displays description of the selected Error Code.

Note

At least one error code & error description should be maintained for a reject reason code.      

The error code value received from the external systems like Sanctions, EAC is main­tained in the 'User Defined Error Codes' maintenance - PMERRCD.

 

11.1.7.1 SWIFT gpi Confirmation Reject Code Mapping Summary

You can invoke ‘SWIFT gpi Confirmation Reject Code Mapping Summary’ screen by typing ‘PXSGPIRM’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Authorization Status

l Record Status

l Host Code

l Network Code

l Reject Reason

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

11.1.8 SWIFT gpi/Universal Confirmation - Manual Generation

This screen displays the transaction details and fields related to gpi/Universal confirmation message generation.

You can invoke ‘SWIFT gpi/Universal Confirmation - Manual Generation’ screen by typing ‘PXDGPIMC’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Below listed fields of transaction are displayed:

l Transaction Reference Number

l Source Reference Number - Field 20 of the Incoming message

l UETR

l Host Code

l Network Code

l

l Transaction Type

l Transfer amount

l Transfer currency

l Credit Amount

l Credit Account currency

l Exchange Rate

l Charge Whom

l Confirmation Status

l Confirmation Type

l Network Type Code

You can specify the following details:

Confirmation Message Details

Status Code

This field lists all gCCT Confirmation Status Codes from SWIFT gpi Static Preferences (PXDGPIST) maintenances.

Status Reason

This field lists all gCCT Status Reason codes from SWIFT gpi Static Preferences (PXDGPIST) maintenances.

Reject Reason

Displays all the gpi Reject Reason Codes maintained in the SWIFT gpi Static Preferences (PXDGPIST) maintenances.

Confirmation Reference

Displays new Reference number generated for the confirmation message.

Confirmation Date Time

Displays Today's date

Status Originator

Displays Default Branch BIC.

Forwarded-to-Agent

Select from the list of values for BIC. The list contains all valid open/authorized BICs.

11.1.8.1 SWIFT gpi/Universal Confirmation - Manual Generation Summary

You can invoke ‘SWIFT gpi/Universal Confirmation - Manual Generation Summary’ screen by typing ‘PXSGPIMC’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Transaction Reference Number

l Payment Type

l Host Code

l gpi Agent

l Confirmation Reference

l UETR

l Source Reference Number

l Confirmation Status

l Network Code

l Transaction Type

l Authorization Status

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

11.2 gCCT Transaction Processing

11.2.1 Outbound gCCT Processing

l gpi enabled Transaction:

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

– System checks if ‘gpi Processing Enabled’ flag is set to ‘Y’ at host level (Function ID: PXDGPIPF). If Yes, system applies gpi payments processor logic. If No, it gets processed as normal SWIFT payments.

–  If ‘gpi Processing Enabled’ flag is set to ‘Y’, then system checks Sender BIC (Processing branch BIC – Default BIC (11-character) linked in Branch Core Parameters screen (STDCRBRN)) and Transfer Currency combination is present in SWIFT gpi Directory (Function ID: PMDGPIDR).

– If ‘Yes’, then the transaction is stamped as ‘gpi enabled’ and will be processed as a SWIFT gpi transaction.

– If ‘No’, then the ‘gpi enabled’ flag is set as ‘No’ and the transaction gets processed as normal SWIFT transaction.

l Currency Cutoff Time Check:

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.

Cutoff Time Calculation Changes: 

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 not present in gpi directory, system picks up the given cutoff time (example, 1400) and the offset time (0900) from the gpi directory

– 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,

l MT 103 - Block 3 Fields Population:

– Field 111 is populated with service id ’001’ in FIN Block 3 of MT 103 message.

– System automatically picks up the service id based on the maintenance done in the screen (PXDGPIST) for the message type gCCT.

l MT 103 - Field 57A Population:

l 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.

 

l 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.

Pass-through Payments Processing:

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

l ‘Inbound gpi’ checkbox

 

l 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’

l 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

 

l 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.

Charge Option OUR:

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

l 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.

l 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.

l 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.

 

Sample:

l :71F:EUR8,00

l :71F:USD5,00

l :71F:EUR0,00

11.2.2 Inbound gCCT processing

The Outbound MT 199 gCCT confirmation generation functionality remains same as below

System performs the following during the incoming MT 103 payment message processing

If the ‘gpi Agent’ sets to ‘No’ as per above tables functionality, then system generates MT 199 gCCT confirmation messages (without Field 111) after RMA+ validation for Tracker BIC as explained above in the Outbound (pass-through) section.

 

System sets ‘gpi Agent’ to ‘Yes’ if the processing branch BIC/transfer currency is present in gpi directory.

 

                  System performs the below operations when ‘Incoming gpi flag’ is ‘No’

úNetwork Cutoff Time Check is done as for normal SWIFT incoming payments from the Inbound BIC Cutoff time (PXDINCOF)

úMT 199 gets triggered automatically when the ‘71A’ is ‘OUR’ and 71G is lesser than the calculated charges. This can be triggered manually without any restriction

úGenerates gCCT confirmation message with 111:001 (RMA+ validation not required)

 Network Cutoff Time Check:

l For ‘gpi Enabled’ = ‘Yes’

– Sender BIC (11-Character BIC as received in the Block 2 of the Inbound MT message) is considered from the new screen (PXDSRIAG) for Inbound gpi payments sender agreement, if present.

– If not present, cutoff time is taken from the gpi directory for the Processing branch BIC (11-Character BIC as received in Block1 of the Inbound MT message), Transfer Currency combination.

– If not found as in step (2), cutoff time is taken from the gpi directory for the Processing branch BIC (11-Character BIC maintained as default BIC in STDCRBRN), Transfer Currency combination.

– If the gpi transaction passed this cut-off time, then the transaction moves to Network Cutoff queue.

Charge Option OUR:

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

l 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.

l If 71G is less than calculated charges,

– System suppresses generation of MT 191 charge claim advice for gpi payments. A validation is added 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 is used.

– Expense GL maintained in Charge Claim Default preferences is debited in DRLQ and Receivable GL from the same maintenance is credited.

11.3 gCOV Transaction Processing

11.3.1 Outbound gCOV processing (Debtor/ Instructing Agent)

l gCOV Transaction:

If the ‘gpi Enabled’ customer transfer is done through cover method, the cover message will be treated as gCOV message for ‘Cross Border’/’RTGS’ payment types.

– Block 3 gpi tags ‘111’ will be populated with value ‘001’. System automatically picks up the service id based on the maintenance done in the screen (PXDGPIST) for the message type gCOV

l Currency Cut-off Time Check:

– In case of gCOV cover method (as part of gCCT processing), system considers only the gCCT leg currency cut-off time for processing Outbound payments. (i.e. System will not check the receiver cutoff time for the Receiver of Cover).

Pass Through gCOV Processing (Reimbursement Agent)

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

l ‘Inbound gpi’ checkbox

– ‘Inbound gpi’ check box is set to 'Y' if an Inbound payment (MT 202COV/MT 205COV) has gpi tags (111:001) and is resulting in an Outbound payment (gpi/non-gpi).

– ‘Inbound gpi’ check box is set to 'N' if an Inbound non-gpi payment resulting in an Outbound payment(gpi/non-gpi).

l ‘gpi enabled’ Check:

– System first checks if ‘gpi Processing Enabled’ flag is set to ‘Y’ at host level (Function ID: PXDGPIPF). If Yes, system applies gpi payments processor logic. If No, it is processed as normal SWIFT payments.

– If ‘gpi Processing Enabled’ flag is set to ‘Y’, then system will check

– Sender BIC (Processing branch BIC – Default BIC (11-character) linked in Branch Core Parameters screen (STDCRBRN)) and Transfer Currency combination is present in SWIFT gpi Directory (Function ID: PMDGPIDR).

– If ‘Yes’, then the transaction is stamped as ‘gpi enabled’ and is processed as a SWIFT gpi transaction.

– System populates gpi tags ‘111’ with value ‘001’ and ‘121’ with same UETR as the underlying Inbound gCOV in FIN block 3 of MT 202COV/205COV.

– If ‘No’, then the ‘gpi enabled’ flag is set as ‘No’ and the transaction is processed as normal SWIFT transaction.

– System performs validations and processing as applicable for Outbound ‘gpi enabled’ transactions as detailed in previous section.

l Currency Cut-off Time Check:

l Below validations are done when Inbound cover message resulting in an Outbound gCOV,

– If Receiver of MT 202COV/205COV BIC, CCY is identified as gpi agent as per gpi directory then system will check if Outbound gpi payment receiver agreement is present in the new screen (PXDSROAG),

– If present, Outbound cut-off time is considered from here.

– If not, Outbound cut-off time is taken from the gpi directory for the Receiver BIC, Currency combination.

– If the transaction passed this cut-off time, then the transaction moves to Network cut-off queue.

l MT 202COV/MT 205 COV - Fields 52A, 57A Population: 

For gpi enabled ‘Cross Border’ payments, changes will be done to populate Field 57A even if AWI is same as that of Receiver of the message. Field 52A, as applicable (Ordering Institution), 58A (Beneficiary Institution) will be populated in the gCOV MT 202COV/MT 205COV message generated.

– Field 52A: In case of pass thru, 52A is added if in the Inbound MT COV this field is absent

– Field 57A is populated even if AWI is same as that of Receiver of Outbound cover payment message.

11.3.2 Inbound gCOV Processing

MT 299 gCOV confirmation message gets generated for all statuses(//ACCC, //ACSP, //RJCT) for the below specific case

l When the Incoming gpi is ‘N’ and gpi agent is ‘Y’

– 111:001 gets copied to Block 3 of the message

– RMA+ validation is not performed for Tracker BIC

– Network Cutoff Time Check is done as for normal SWIFT incoming payments from the Inbound BIC Cutoff time (PXDINCOF)

System does not generates MT 299 gCOV confirmation message when Incoming gpi is ‘Y’ and gpi agent is ‘N’.

Network Cutoff Time Check:

l For ‘gpi Enabled’ = ‘Yes’

– Sender BIC (11-Character BIC as received in the Block 2 of the inbound MT message) is considered from the screen (PXDSRIAG) for inbound gpi payments sender agreement, if present.

– If not present, cutoff time is taken from the gpi directory for the Processing branch BIC (11-Character BIC as received in Block1 of the inbound MT message), Transfer Currency combination.

– If not found as in step (2), cutoff time is taken from the gpi directory for the Processing branch BIC (11-Character BIC maintained as default BIC in STDCRBRN), Transfer Currency combination.

– If the gpi transaction passed this cut-off time, then the transaction moves to Network Cutoff queue.

Incoming gCOV Payments

Outbound MT 299 gCOV confirmation generation

l System performs the following to set ‘gpi Agent’ to ‘Yes’ or ‘No’ during the process of incoming COV messages

 

l If gpi Agent is ‘No’ and ‘incoming gpi’ is ‘Y’ then system should not generate MT 299 gCOV confirmation message

l System sets ‘gpi Agent’ to ‘Yes’ if processing branch BIC/transfer currency is present in gpi directory.

l System performs below operations as per existing functionality when the ‘incoming gpi flag’ is ‘N’

– Network Cutoff Time Check is done as for normal SWIFT incoming payments from the Inbound BIC Cutoff time (PXDINCOF)

– Generates gCOV confirmation message with 111:001 (RMA+ validation not required) for all statuses.

11.4 gCCT Confirmations - MT 199

11.4.1 Outbound gCCT Confirmations - MT 199 Generation

Note

The system does not perform RMA validation on the generated gpi/universal confirmation.

 

Below are the additional changes to MT 199 gCCT confirmation messages generation after processing of inbound or pass through gCCT payments by the gpi bank

l System generates gCCT MT 199 confirmation message for final credit confirmation (//ACCC), Intermediate status confirmation (//ACSP/G002/G003/G004) and for final reject status (//RJCT) as shown below when the processing branch is non-gpi agent

l Below changes are supported when the processing branch is gpi agent as per existing functionality

Note

System do not generate MT 199gCCT confirmations if 'Generate gpi confirmations' value is unchecked (set to 'N').

Inbound transactions initiated either manually through UI or through SOAP/Rest service, 'Generate gpi confirmations' will always be set to 'N' (if not indicated).

Inbound transactions uploaded through SWIFT, 'Generate gpi Confirmations' field value will always be set to 'Y' (Checked).

 

Note

The Auto job 'PQDPRQUE' - 'Job Code for Process Exception MT 199 transaction' gener­ates the Interim gpi confirmations at EOD. Configure this job to run at a pre-defined time

daily.

 

 

l Tracker BIC address is referred from the gpi Host preferences maintenance (PXDGPIPF).

l System picks up the confirmation Status code based on the maintenance done in the screen (PXDGPIST) for the message type gCCT/gCOV.

l System picks up the confirmation Reason code based on the maintenance done in the screen (PXDGPIST) for the message type gCCT when the payment processing status is ‘INPROGRESS’.

Note

l SWIFT gpi Tracker generates gCCT confirmations to gpi agents automatically in case of ACSP/G000 and ACSP/G001, based on content of transferred MT 103 or MT 202/5 COV on FIN network. So, OBPM doesn't generate confirmation messages.

 

11.4.1.1 Reject Confirmation - Reason code population

For manual cancellation from exception queues (Cancel User action), the reason code captured during cancellation processing is populated.

For auto cancellation of transactions, the reason code is populated as below:

l The Error Code received in the external system response is checked against the SWIFT gpi Confirmation Reject Code Mapping (PXDGPIRJ)

l If a valid (Open/Authorized) mapping maintenance is found, then the Reject Reason code is populated.

l If no valid mapping maintenance is found, the default Reject Reason code 'MS03' is populated.

For Reject Confirmation message generated during gSRP cancellation request processing, is done to populate the Confirmation Reject Reason code captured during gSRP cancellation - Accept User action.

Reject Reason code is populated in the Line 2 of Confirmation message.

l E.g. //RJCT/AC01

 

11.4.2 Inbound gCCT Confirmations - MT 199 Message Processing

For FIN based Tracker Interaction type, Inbound MT 199 gCCT confirmation message is uploaded to daily Message In data store and linked to the original Outbound gCCT MT 103 payment.

l Matching criteria is as follows – From Block 3

– 121:UETR of gCCT MT 103 = 121:UETR  of MT 199 gCCT confirmation

l After successful match, the message is parsed and the same is stored to show them at the Outbound transaction view screen.

 

The 'Settlement Method' & 'Clearing System Code' values are expected in Field 79 - Line 3. The 'Details of Charges' value is expected in Field 79 - Line 4.

11.4.2.1 Inbound gpi Confirmations Summary

You can view all inbound gpi confirmations (MT 199/MT 299) received with match status 'Pending Match', 'Matched' in this screen.

You can invoke the ‘Inbound gpi Confirmations Summary’ screen by typing ‘PXSIGPCN’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button.

You can search using one or more of the following parameters.

l UETR

l Message Reference

l Message Date

l Service Identifier

l Branch Code

l Our Transaction Reference

l Confirmation For

l Status (Pending Match/ Match)

l Our Transaction Network Type Code

Once you have specified the search parameters. Click ‘Search’ button. The system displays the records that match the search criteria.

Double click a record or click the ‘Details’ button after selecting a record to view the detailed screen.

11.4.3 Auto Confirmation Message Generation Processing

Auto generation of gpi/Universal confirmation message is done if the 'gpi/Universal Confirmation Message Generation Preference' is maintained as 'Automatic' in the SWIFT gpi Host level preference. This will be applicable for

l Interim confirmation messages that are getting generated by the Auto Job 'PQDPRQUE' which should be configured to run at a pre-defined time daily for Interim confirmation generation

l Credit confirmation messages that are getting generated on successful processing of an Incoming transaction

l Reject confirmation messages that are getting generated due to cancellation processing (triggered by reject response from external systems).

Once a gpi/Universal confirmation message is generated successfully, the 'Confirmation Status' value is updated as 'Generated' if the previous status is 'Ungenerated' and 'Confirmation Type' is marked as 'Interim' or 'Reject' or 'Credit' depending on the confirmation message generated.

In the gpi Confirmations sub screen, the field 'Generation Type' Mode' is marked as 'Automatic'.

Note

For Incoming Cross Border transactions booked via Incoming Cross Border SOAP/REST services, there is a provision to indicate whether gpi / Universal confirmation generation is required or not. If this option is set as No, then gpi / Universal confirmation do not get gen­erated irrespective of whether the confirmation message generation preference mode is 'Automatic' or 'Manual'.

 

11.4.4 Manual Confirmation Message Generation Processing

After successful validation and authorization of the Manual Confirmation input by user, the confirmation message generation is done.

A gpi Confirmation message gets generated if the 'gpi Agent' flag is 'Yes'. Otherwise, a Universal confirmation message gets generated.

In case of gpi Confirmation message, the Field 111 in Block 3 is populated with a value of '001' [Value is taken from SWIFT gpi Static preference maintenance (PXDGPIST) ]. The value population for other fields is same as done for Universal confirmation message generation.

Once a gpi/Universal confirmation message is generated successfully, the 'Confirmation Status' value is updated as 'Generated' if the previous status is 'Ungenerated' or blank and 'Confirmation Type' is marked as 'Interim' or 'Reject' or 'Credit' depending on the confirmation message generated.

In the gpi Confirmations sub screen, the field 'Generation Type ''Generation Mode' is marked as 'Manual'.

Refer the below table for the supported Status Code and Status Reason/Reject Reason codes for Payment types/Transaction types:

Note

 

The manual gpi/Universal confirmation message can be generated even if the gpi/Univer­sal confirmation message generation preference is 'Automatic' in SWIFT gpi Host prefer­ences maintenance (PXDGPIPF) based on the transaction status. E.g. An interim confirmation can be generated before OBPM generates the same during EOD.

 

 

11.5 gCOV Confirmations - MT 299

Note

The system does not perform RMA validation on the generated gpi/universal confirmation.

 

11.5.1 Outbound gCOV Confirmations - MT 299 Message Generation

The gCOV MT 299 confirmation message is generated with fields 20,21,79. The Outbound MT 299 gCOV confirmation message will be automatically linked to the pass-thru or original Inbound gCOV transaction.

l BIC address to send MT 299 confirmation to Tracker is referred from the gpi Host preferences maintenance (PXDGPIPF). System will not perform RMA/RMA+ validation on the Tracker BIC.

l Fields 20 (Transaction Reference), 21 (gCOV reference of F20 of MT 202COV/MT 205COV) and 79.

l Block 3 of the FIN message has gpi tags 111:001, 121: UETR of gCOV.

l Field 79 of the status confirmation message MT 299, populates the following details:

Line 1

l //date and time

l //1601121515+1300

Date & Time Format:

 Date in YYMMDD format and Time in HHMM and the time zone (of Host) in which "time" is expressed is to be identified by means of the offset (positive or negative) against the UTC.

Note

Time offset HH will be <=13 and MM will be <=59

 

Line 2

l //status code [/reason code]

gCOV confirmation messages by Intermediary Reimbursement /Last Reimbursement Agent

 

l gCOV confirmation messages by gCOV Instructed Agent

 

Line 3

l //status originator (BIC)[/ forwarded to (BIC)]

Status Originator field:

 This contains the BIC code of the gpi bank that provided the status in the gCOV Confirmation (standard MT representation for identifier code: 4!a2!a2!c[3!c]), optionally followed by the identifier (BIC) of the financial institution to which the gCOV leg was transferred.

Forwarded-to agent field:

This field informs recipients of gCOV confirmations to which agent the gCOV leg was transferred to.

**Presence of this field is mandatory when confirmation status is ACSP/G000

l Example: //GPIBBICXXXX/GPICBICXXX

Line 4

//currency and amount

l Currency includes currency used in field 32A of gCOV leg with format 3!a

l Amount includes amount used in field 32A of gCOV leg with format 15d

l For ACCC, RJCT, ACSP/G002 and ACSP/G003, the "gCOV leg" to consider is the Inbound one for the currency field value.

l For ACSP/G000 and ACSP/G001, the "gCOV leg" is the Outbound one for the currency field value

Note

There will not be any Sanctions Check validation done for the gpi Confirmation messages.

The Tracker generates gCOV confirmations to gpi agents automatically in case of ACSP/G000 and ACSP/G001, based on content of transferred MT 103 or MT 202/5 COV on FIN network.

 

11.5.1.1 Reject Confirmation - Reason code population

For manual cancellation from exception queues (Cancel User action), the reason code captured during cancellation processing is populated.

For auto cancellation of transactions, the reason code is populated as below:

l The Error Code received in the external system response is checked against the SWIFT gpi Confirmation Reject Code Mapping (PXDGPIRJ)

l If a valid (Open/Authorized) mapping maintenance is found, then the Reject Reason code is populated.

l If no valid mapping maintenance is found, the default Reject Reason code 'MS03' is populated.

For Reject Confirmation message generated during gSRP cancellation request processing, is done to populate the Confirmation Reject Reason code captured during gSRP cancellation - Accept User action.

Reject Reason code is populated in the Line 2 of Confirmation message.

l E.g. //RJCT/AC01

 

11.5.2 Inbound gCOV Confirmations MT 299 Message Processing

For FIN based Tracker Interaction type,

Inbound MT 299 gCOV confirmation message is uploaded to daily Message In data store and linked to the original outbound gCOV MT 202COV/MT 205COV payment.

l Matching criteria is as follows – Block 3

– 121: UETR of gCOV MT 202COV/MT 205COV = 121:UETR of MT 299 gCOV confirmation

Inbound MT 299 gCOV confirmation message is linked to an inbound gCCT payment at gCOV instructed agent.

l Matching with an inbound gCCT transaction in any processing status (waiting for Cover match / In Progress / Processed)

– 121: UETR of gCCT MT 103 = 121: UETR of MT 299 gCOV confirmation

The 'Settlement Method', 'Clearing System Code' and 'Details of Charges' values received in the incoming confirmation message is parsed and captured in the gpi Confirmations data store to show in the gpi Confirmation sub screens.

The 'Settlement Method' & 'Clearing System Code' values are expected in Field 79 - Line 3. The 'Details of Charges' value is expected in Field 79 - Line 4.

11.5.2.1 Inbound gpi Confirmations Summary

You can view all inbound gpi confirmations (MT 199/MT 299) received with match status 'Pending Match', 'Matched' in this screen.

You can invoke the ‘Inbound gpi Confirmations Summary’ screen by typing ‘PXSIGPCN’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button.

For more details on the screen and its fields, refer to section 4.3.2.1

 

11.6 Notifications

For every inbound gpi confirmation message (MT 199 gCCT), notification is trggered (for debtor), if the ‘gpi Processing Enable’ flag is checked at Host Level.

gCCT Instructing Agent

Based on the gpi Notification Preferences maintained at Customer level (PMDFLPRF), the following notifications are generated:

l When ‘On Interim Confirmation’ flag is checked, system auto generates notification to debtor and an Interim Confirmation message is received.

l When ‘On Final Confirmation’ flag is checked, system auto generates notification to debtor and Final Confirmation message is received.

Identifying Interim/ Final Confirmations

Status Code in the received MT 199 is mapped with ‘Payment Processing Status’ in gpi Statis Preferences screen (PXDGPIST). Notifications are generated in the following conditions:

l System generates Interim confirmation notifications, if the derived ‘Payment Processing Status’ is “INPROGRESS”.

l System generates Final confirmation notifications, if the derived ‘Payment Processing Status’ is “PROCESSED” or “REJECTED”.

System will parse the below contents as received in the gpi confirmation and populate it in the new tags to generate notification

l [Following lines //any deducts by status originator(s)]

l The new XML tags listed will be under ‘gpiConfirmInfo” XML node

l gCCT Instructed Bank

l The credit notification will have the tags - ‘gpi Enabled Flag’ and ‘UETR’

l The notifications further can be triggered through the modes - SMS/ E-Mail.

11.7 gSRP Cancellation Processing

11.7.1 Outbound Cancellation Request Processing

11.7.1.1 Dispatched/ Processed Payments

If the transaction is already dispatched (or) payment message is generated successfully, then the cancellation processing is done based on the payment type.

Cross Border Payment Type

l If the payment message generation is suppressed, the cancellation processing is done as below

– Cancellation processing for the transaction is initiated

– Cancellation status of Cancellation request is marked as ‘Cancelled’

– Reversal accounting entries are posted and sent to accounting system

l If the Transfer Type is ‘Bank Transfer Own A/c’, the cancellation processing is done as below

– Cancellation status of Cancellation request is marked as ‘Exception’. Error code & error reasons are updated

l The acknowledgement status of the payment message is checked

l If the acknowledgement status is pending from SWIFT, then the system waits for the acknowledgment message. Once the acknowledgement is received, system does the cancellation processing based on the acknowledgment status

Note

For Customer transfer with cover transaction, the acknowledgement status of the custom­er transfer only is checked.

 

RTGS Payment Type

l The acknowledgement status of the payment message sent out is checked.

l If the acknowledgement status is pending, then the system waits for the acknowledgment message from SWIFT Once the acknowledgement is received, system does the cancellation processing based on the acknowledgement status and on the ‘Sender Notification Required’ flag at Network Preference maintenance (PMDNWPRF).

– If the ‘Sender Notification Required’ flag is un-checked at the network preference level, the cancellation processing will be done based on the acknowledgement status

l If the ‘Sender Notification Required’ flag is checked at the network preference level, the cancellation processing is done based on the RTGS network acknowledgement status.

Note

l Payment message status is marked as ‘Suppressed’ to restrict users from repairing and resending the message from Outbound message browser

l Upon successful cancellation processing, the transaction status is marked as ‘Canceled’   

 

11.7.1.2 MT n92 / gSRP Request Message Generation

MT n92 message generation

If the outbound transaction is identified as ‘non-gpi’ message, then system automatically generates MT 192/MT 292 as per standard format.

l Message type is MT 192 if the outbound transaction type is customer transfer type. It is MT 292 if the outbound transaction type is bank transfer type

l Receiver of the message is populated same as the receiver of the original outbound transaction payment message

l Field 20 sender reference number is populated with cancellation request reference

l Field 21 related reference number is populated with outbound transaction reference

l Field 11S with the outbound payment message type and message date

l Field 79 with the ‘Narrative (79) Line 1’ field, Narrative lines 2 to 35 field values if given by user

l Copy of the  original payment message is populated if the flag ‘Copy of at least the Mandatory Fields of the Original Message is checked

Note

As per the existing functionality, the optional fields also gets populated.

 

gSRP Request message generation

If the outbound transaction is identified as ‘gpi’ message, then system generates gSRP request as MT 192 message or MT 199 message based on the ‘gSRP Request Message Type’ gpi Host preference (PXDGPIPF).

l Message type is MT 192 if the ‘gSRP Request Message Type’ selected is 192 It is MT 199 if the preference is selected as MT 199.

l Receiver of the message is Tracker BIC (TRCKCHZZ) value populated in gpi Host preference (PXDGPIPF)

l Field 111 is populated with the service type identifier (002) value maintained for gSRP in gpi Static Preference maintenance.

l Field 121 is populated with the UETR of the outbound transaction

l Field 20 sender reference number is populated with cancellation request reference

l Field 21 related reference number is populated with outbound transaction reference

l Field 11S with the outbound payment message type and message date if the ‘gSRP Request message type’ is MT 192.

l Field 79 with the ‘Narrative (79) Line 1’ value given by user in the Transaction Cancellation request message.

RMA/RMA+ Validation

l RMA/RMA+ validation is done for gSRP request messages also. Validation is done based on the gSRP request message type, Branch default BIC, Tracker BIC and message generation date

– Cancellation status is marked as ‘Exception’. Error code & error reason gets updated.

– No gSRP request is generated

Sanction Check

gSRP request messages undergoes Sanctions Check processing. The processing is same as done for the normal MT n92/MT n99 messages.

Note

l For Customer transfer with cover transaction, the gSRP/MT n92 request message is generated only for the customer transfer

l The successfully generated request messages can be viewed from the ‘Recall Messages’ screen of Outbound Cross Border Payments View (PXDOVIEW)

 

Recall Request Log

After successful generation of MT n92/gSRP Request message, the recall request is logged for the Outbound transaction.

l Recall Reference – Field 20 of n92/gSRP request

l Recall Date – Date on which n92/gSRP request sent out

l Recall Reason Code – Reason Code selected for n92/gSRP request

l Recall Reason – Value given in ‘Narrative (79) Line 1’ field after the Reason code by user.

11.7.2 Outbound Cancellation Response Processing

l MT n96 messages received from SWIFT is treated as Cancellation Response messages and these messages are classified as gSRP Response or non-gSRP response messages.

l SWIFT gpi Tracker sends gSRP status notifications and alerts as MT 199 messages. So, MT 199 messages are also be checked for Cancellation response processing.

11.7.2.1 gSRP Response Message Processing

l Changes are done to parse and do the STP of the Inbound MT 196/MT 199 messages.

l If the message has Field 111 service type identifier, then the message is considered as gSRP response message. The response message is matched with the original outbound gSRP request message and outbound transaction. The matching criteria is as follows

– UETR of Inbound gSRP with UETR of the Outbound transaction/Outbound gSRP request

l The Field 79 line 1 is checked for the response code [‘/’ followed by 4 characters]. Based on the reason code, the response message processing happens

l The Recall response is logged against the original outbound transaction and is shown under ‘Responses’ tab of ‘Recall Messages’ screen.

Note

Field 79 Line 1 starts with ‘//’ in gCCT confirmation message - MT 199.

 

11.7.2.2 Tracker gSRP Status Notification & gSRP Alerts

l If the Field 79 Line 1 of the MT 199 message contains the reason code ‘/PDCR/’ and followed by any of the response codes, the message is  treated as gSRP Status notification message.

– S000   (=valid gSRP request received by Tracker)

– S001   (=gCCT UETR registered in network cancellation list)

– S002   (=gSRP network stop occurred on related UETR)

– S003   (=gSRP Tracker forwarded request to processing/last gpi agent)

– S004   (=Tracker received network delivery acknowledgement (UACK) of gSRP request forwarded to processing/last gpi agent, response pending.)

l If the Field 79 Line 1 of the MT 199 message contains the reason code ‘/RJCR/’ and followed by the response codes /FRNA/, then the message is treated as gSRP alert.

– /RJCR/FRNA (gSRP request does not relate to a gpi payment)

l The status notifications and alerts are logged under recall response against outbound payment transaction and are shown under Tracker Alerts & Status Notifications tab of ‘Recall Messages’ screen

11.7.2.3 MT n96 Response Processing

l The Inbound MT n96 message is matched with the original outbound transaction. The matching criteria is as follows

– Field 21 of the MT 196 with the outbound cancellation request reference.

l The Field 79 line 1 is checked for the response code [‘/’ followed by 4 characters]. Based on the reason code, the response message processing happens

l If the Inbound n96 message doesn’t have any response code, then the Recall status of transaction is not updated. The Recall response is logged against the original outbound transaction and is shown under ‘Responses’ tab of ‘Recall Message’ screen

11.7.2.4 Recall Response Log

l The recall response messages after successful match with original outbound transaction, the response is logged against outbound transaction and is shown in the ‘Exception’ tab under ‘Recall Response’.

– Response Reference – Field 20 of n96/gSRP Response/Alert/Status notifications

– Response Date – Date on which n96/gSRP Response/Alert/Status notification sent out

– Response Message Type – Message type of response message [MT 196/MT 296/MT 199]

– Response Code – Response Status code received in first 4 characters in Field 76 Line 1 of MT n96/Field 79 Line 1 of MT 199

– Recall Reason – Reason code received after the Response status code in Field 76 Line 1 of MT n96/Field 79 Line 1 of MT 199

11.7.3 Inbound Cancellation Request Processing

l All incoming cancellation request messages (MT n92) is parsed and is classified as gSRP request message (or) a non-gSRP request message.

– If the incoming MT 192 message is having a value ‘002’ in Field 111 and a UETR value in Field 121, then the message is treated as a gSRP request message.

l After successfully parsing and classifying the incoming cancellation request message, the message is populated into the newly introduced ‘Inbound Cancellation Browser’ with the Process Status as ‘Unprocessed’. The gSRP flag value is populated as ‘Yes’ if the cancellation request message is a gSRP request message

11.7.3.1 Matching with Inbound Payments

l The incoming cancellation request message is matched with an Inbound Cross Border / RTGS transaction based on the Incoming SWIFT Payment view (PSDIVIEW) tables. Matching criteria for gSRP request and non-gSRP request is as follows:

– For gSRP requests, Field 121 UETR of Incoming message is matched with the UETR of the Inbound transaction

– For non-gSRP MT n92 requests, Field 21 of the incoming message with the Inbound transaction source reference and sender of the MT n92 request with the Inbound transaction sender bank value

l Once the Incoming MT n92/gSRP request message is successfully matched, then system does below things

– Process Status value is updated as ‘Matched’ in the Inbound Cancellation Browser.

– Queue action log is populated with action as ‘MATCH’ along with maker/checker ids asl SYSTEM and maker/checker timestamps against the Cancellation Request message

– A recall request record is logged to show under ‘Exception’ screen of Inbound Transaction view screen.

l If the matched Inbound transaction status is in Progress (or)  transaction status is Exception and in any external queue, the cancellation request is logged in a cross border inbound queue cancellation request table which is referred during inbound processing key steps. The list of external queues considered are

– Sanction Check

– EAC

– External Exchange Rate

– External Pricing

l Cancellation processing for an Inbound transaction is done based on the transaction status and queue code

11.7.3.2 Processed Payments

Transaction Status – Processed

l If the transaction status is in ‘Processed’, then

– Recall Status at transaction is updated as ‘Recall Requested’

– Process Status at Inbound Cancellation Browser is updated as ‘Transaction Locked’

– Transaction is moved to the Inbound Cancellation Request queue

– Transaction Status is updated as ‘Processed’, last queue code as ‘##’ and Current status as ‘Pending’ in the Inbound Cancellation Request queue

– Queue action is logged for transaction moving to Inbound Cancellation Request queue

Transaction Status – Seized / Cancelled

l If the transaction status is -seized/ cancelled, then

– Recall Status at transaction is updated as ‘Recall Requested’

– Process Status at Inbound Cancellation Browser is updated as ‘Transaction Locked’

– Transaction is moved to the Inbound Cancellation Request queue

– Transaction Status is updated with the current transaction status, last queue code as ‘##’ and Current status as ‘Pending’ in the Inbound Cancellation Request queue

– Queue action is logged for transaction moving to Inbound Cancellation Request queue

11.7.3.3 Unprocessed Payments

Transaction in STP Queue

If the transaction status is in STP Queue, then the system waits for the auto cover match to happen (or) for the manual user action.

Transaction Status – Future Valued

l If the transaction status is ‘Future Valued’ – in ‘Warehouse Queue’, then.

– Recall Status at transaction is updated as ‘Recall Requested’

– Process Status at Inbound Cancellation Browser is updated as ‘Transaction Locked’

– Transaction is moved out of the Future Dated queue and Transaction is moved to the Inbound Cancellation Request queue

– Transaction Status is updated as the ‘Future Valued’, last queue code as ‘FV’ and Current status as ‘Pending’ in the Inbound Cancellation Request queue

– Queue action is logged for transaction moving out of the Future Dated and for moving to Inbound Cancellation Request queue.

Transaction Status – Exception / In Progress

l If the transaction status is ‘Exception’, then whether the transaction is in an Internal queue or not is checked.

l If the transaction is in an Internal exception queue and the last queue action authorization status is ‘Authorized’, then the following actions are taken on the transaction

– Recall Status at transaction is updated as ‘Recall Requested’

– Process Status at Inbound Cancellation Browser is updated as ‘Transaction Locked’

– Transaction is moved of the internal queue and is moved to the Inbound Cancellation Request queue

– Transaction Status is updated as ‘Exception’, last queue code as the Internal queue code and Current status as ‘Pending’ in the Inbound Cancellation Request queue

– Queue action is logged for transaction moving out of the internal queue and for moving to Inbound Cancellation Request queue

List of internal queues considered are

– Settlement Review

– Transaction Repair

– Processing Exception

– Business Override

– Authorization Limit 1

– Authorization Limit 2

– Exchange Rate

– Network Cutoff

l If the transaction is in an Internal exception queue and the last queue action authorization status is ‘Unauthorized’, then based on the user action cancellation processing happens

List of internal queues that will be considered as follows

– Settlement Review

– Transaction Repair

– Processing Exception

– Business Override

– Processing Cutoff

– Exchange Rate

– Network Cutoff

l If the transaction is in any external queue, then the cancellation processing is done once the transaction is out of the external queue

l The cancellation request check introduced in key processing steps of inbound transaction processing does cancellation processing as mentioned below

l In the external queues, the ‘Carry Forward’ action is not allowed if a cancellation request is found for a transaction

 

11.7.4 Inbound Cancellation Request - Response Processing

All the Inbound Cancellation requests – both matched with an Inbound Transaction /Transaction in STP queue as well as Unmatched are logged into the Cancellation queue

11.7.4.1 Cancellation Response Processing

Based on the user action selected in the Inbound Cancellation Request queue and based on the current transaction status, last queue code / action combination, the cancellation response processing is done.

Interim Response

l On authorization of the Interim action, the system does the below listed processing steps

– A gSRP Response message is generated if the recall request is a gSRP request message. Otherwise, a non-gSRP MT n96 response message is generated

– A Recall response is logged to show in the Inbound Transaction view – Under Exception – screen

– Queue action is logged for the Interim action against the transaction reference

The details of the gSRP response message / non-gpi MT n96 response message are explained in the following section

Accept

l On authorization of the Accept action, the following changes will be done

– A gSRP Response message is generated if the recall request is a gSRP request message. Otherwise, a non-gSRP MT n96 response message is generated

– A gCCT reject response message is generated if the recall request is a gSRP request and last queue code is not blank

– Inbound Cancellation queue level Current Status field is updated as ‘Accepted’

– Last Response action at Cancellation browser is updated as ‘Accepted’

– Recall status at transaction is updated as ‘Accepted’.

– Recall response is logged to show in the Inbound Transaction view – Under Exception – screen

– Transaction is moved out of the cancellation request queue

– Queue action is logged for the ‘Accepted’ action at the transaction level

– Cancellation processing for the transaction initiated if the transaction status is not Processed / Cancelled / Seized [i.e. Transaction Status is ‘In Progress’]

Note

Upon successful cancellation processing, the transaction status is marked as ‘Cancelled’

 

Reject

On authorization of the Reject action, the following changes are done

l A gSRP Response message if the recall request is a gSRP request message is generated. Otherwise, a non-gSRP MT n96 response message is generated.

l Inbound Cancellation queue level Current Status field is updated as ‘Rejected’

l Last Response action at Cancellation browser is updated as ‘Rejected’

l Recall status at transaction is updated as ‘Rejected’.

l Recall response is logged to show in the Inbound Transaction view – Under Exception – screen

l Transaction is moved out of the queue

l Queue action is logged for the ‘Reject’ action at the transaction level

l If the transaction has not been processed [Last queue code is not blank],

– Transaction is reprocessed same as future valued transaction processing done on the value date. During reprocessing, FX Request is not resent if Reject action was taken on same day.

– Value date/Activation date is re-derived

11.7.4.2 gSRP Response Message

If the inbound transaction is ‘gpi Enabled’, then system generates gSRP response as MT 196 message or MT 199 message based on the ‘gSRP Response Message Type’ preference in gpi Host preference (PXDGPIPF).

l Message type is MT 196 if the ‘gSRP Response Message Type’ selected is MT 196. It is MT 199 if the preference is selected as MT 199.

l Receiver of the message is Tracker BIC (TRCKCHZZ) value populated in gpi Host preference (PXDGPIPF)

l Field 111 is populated with the service type identifier (002) value maintained for gSRP in gpi Static Preference maintenance.

l Field 121 is populated with the UETR of the inbound cancellation request message

l Field 20 sender reference number is populated with cancellation response reference generated in Cancellation response screen

l Field 21 related reference number is populated with inbound recall reference (Field 20).

l

l MT 196 Field 76 Line 1 / MT 199 Field 79 Line 1 is populated with the ‘Answers (76) Line 1’ field value given by user in the Cancellation response screen.

l MT 196 Field 76 Line 2 / MT 199 Field 79 Line 2 is populated with the Branch default BIC.

RMA/RMA+ Validation

l RMA/RMA+ validation is done for gSRP response messages also. Validation is done based on the gSRP response message type, Branch default BIC, Tracker BIC and message generation date. If RMA/RMA+ validation fails, then an error message is shown to the user and the gSRP response message is not generated

Sanction Check

l gSRP response messages undergoes Sanctions Check processing. The processing is same as done for the normal MT n96/MT n99 messages

11.7.4.3 Non-gSRP Response Message

For non-gpi transactions, System generates MT 196 message or MT 299 message based on the MT n92 message received.

– Message type is MT 196 if the cancellation request message received is MT 192. It is MT 296 if the Inbound cancellation request message is MT 292

– Receiver of the message is the Sender of the MT n92 message

– Field 20 sender reference number is populated with cancellation response reference generated in Cancellation response screen

– Field 21 related reference number is populated with inbound recall reference (Field 20)

– Field 76 is populated with the ‘Answers (76) Line 1’ field, ‘Answers (76) Line 2-35’ values given by user in the Cancellation response screen

– Field 77A is populated with the values given by user in the ‘Narrative 77A’ field

– Field 79 is populated with the values given by user in the ‘Narrative 77A’ field.

– Copy of the  original inbound recall message is populated if the flag ‘‘Copy of at least the Mandatory Fields of the Original Message’ is checked

11.7.4.4 Interim gSRP Response Message at EOD

l For Inbound gSRP Cancellation requests, System generates an Interim response message at EOD if there is no action taken by the user on the cancellation request message received date [In Inbound Cancellation Browser]

– Message type is MT 196 if the ‘gSRP Response Message Type’ selected is MT 196. It is MT 199 if the preference is selected as MT 199

– Receiver of the message is Tracker BIC (TRCKCHZZ) value populated in gpi Host preference (PXDGPIPF)

– Field 111 is populated with the service type identifier (002) value maintained for gSRP in gpi Static Preference maintenance

– Field 121 is populated with the UETR of the incoming cancellation request message

– Field 20 sender reference number is populated with a newly generated reference number

– Field 21 related reference number is populated with incoming recall reference (Field 20)

– MT 196 Field 76 Line 1 (or) MT 199 Field 79 Line 1 is populated with Response status as ‘PDCR’ and reason code as ‘RQDA’

Note

The Auto job ‘PQDPRQUE’ – ‘Job Code for Process Exception MT199 transaction’ gener­ates the Interim gSRP response message at EOD. This job should be configured to run at a pre-defined time daily.

 

11.7.4.5 Recall Response Log

l The recall response is logged as below.

– Response Reference – Field 20 of n96/gSRP Response message sent out

– Response Date – Date on which n96/gSRP Response message sent out

– Response Code – Response Status code sent in first 4 characters in Field 76 Line 1 of MT n96/Field 79 Line 1 of MT 199

– Recall Reason – Reason code sent after the Response status code in Field 76 Line 1 of MT n96/Field 79 Line 1 of MT 199

 

11.7.5 Outbound Pass-through Cancellation Request Processing

l Cancellation/Recall request initiation for Outbound pass-through transactions is same as the Cancellation request initiation for Outbound Cross Border/RTGS transactions initiated by our bank. User can initiate the cancellation requests from the  Outbound Cross Border Transaction View Summary (PXSOVIEW) by selecting the transactions and using ‘Cancel Request’ action

l The cancellation processing for outbound pass-through transactions are done on the transaction status, current exception queue.

11.7.5.1 Unprocessed Payments

Transaction Status – Future Dated

If the transaction is in ‘Future Dated’ – in ‘Warehouse Queue’, then the transaction booking date will be checked.

l If the transaction booking date is same as cancellation request date, then the following process happens

– Transaction is moved out of Warehouse queue and transaction cancellation processing is initiated

– Cancellation status is marked as ‘Cancelled’

– Return GL entries  gets posted

– A gpi confirmation message with status code ‘RJCT’ is generated if the transaction is gpi-enabled.

l If the transaction booking date is not the same as cancellation request date, the transaction is sent for Sanctions. The cancellation processing is based on response received from Sanctions system.

Transaction Status – Exception

l If the transaction status is ‘Exception’, then whether the transaction is in an Internal queue or not is checked.

l If the transaction is in an Internal exception queue and the last queue action authorization status is ‘authorized’, then the following actions are taken on the transaction

–

– Transaction is moved out of the queue and transaction cancellation processing is initiated

– Cancellation status is marked as ‘Cancelled’

– FX Reversal Request is sent out if External Exchange Rate was applicable and if the payment is moved out of Network Cutoff queue

– Return GL entries gets posted

– A gpi confirmation message with status code ‘RJCT’ is generated if the transaction is gpi-enabled.

List of internal queues considered are

– Settlement Review

– Transaction Repair

– Processing Exception

– Business Override

– Authorization Limit 1

– Authorization Limit 2

– Processing Cutoff

– Exchange Rate

– Network Cutoff

l In the internal queues, changes are done for the ‘Delete’ action to check if any pending cancellation request is available for the outbound pass-through transaction in the module specific cancellation request table. If any pending cancellation request found, then the following actions are taken on the transaction.

– Transaction is moved out of the internal queue and transaction cancellation processing is initiated

– Cancellation status is marked as ‘Cancelled’

– ECA Reversal Request is sent out if ECA Check was applicable and transaction is in Network Cutoff queue

– FX Reversal Request is sent out if External Exchange Rate was applicable and transaction is in Network Cutoff queue

– Return GL entries gets posted

– A gpi confirmation message with status code ‘RJCT’ is generated if the transaction is gpi Enabled

List of internal queues that are considered

– Settlement Review

– Transaction Repair

– Processing Exception

– Business Override

– Processing Cutoff

– Exchange Rate

– Network Cutoff

l If the transaction is in any external queue [Sanction Check, ECA, External Exchange Rate, External Pricing], then the cancellation processing is done once the transaction is out of the external queue.

l The cancellation request check introduced in key processing steps of outbound transaction processing does cancellation as mentioned below

11.7.5.2

Processed Payments

If the payment message has been generated successfully and sent out, then the cancellation processing is done based on the payment type and acknowledgement from SWIFT / RTGS network.

Cross Border Payment Type

l The acknowledgement status of the payment message sent out is checked.

l If the acknowledgment status is pending, then the system waits for the acknowledgment message from SWIFT. Once the acknowledgment is received, system does the cancellation processing based on the status

RTGS Payment Type

l The acknowledgement status of the payment message sent out is checked.

l If the acknowledgement status is pending, then the system waits for the acknowledgment message from SWIFT

l Once the acknowledgement is received, system does the cancellation processing based on the acknowledgement status and on the ‘Sender Notification Required’ flag at Network Preference maintenance (PMDNWPRF).

– If the ‘Sender Notification Required’ flag is un-checked at the network preference level, the cancellation processing is done based on the acknowledgement status.

l If the ‘Sender Notification Required’ flag is checked at the network preference level, the cancellation processing is done based on the RTGS network acknowledgement status

Note

Message generation processing and Recall request processing is same as mentioned in section MT n92 / gSRP Request Message Generation.

 

11.7.5.3 MT n92/ gSRP Request Message Generation

Message generation processing and Recall request processing is same as mentioned in section MT n92 / gSRP Request Message Generation (4.7.1.4)

11.7.6 Outbound Pass-through Cancellation Response Processing

Cancellation response processing is same as mentioned in section Outbound Cancellation Response Processing (4.7.2).

11.7.7 Inbound Pass-through Cancellation Request Processing

All Inbound cancellation request messages (MT n92) are parsed and is matched with an Inbound transaction. If there is no match found, then the cancellation request is matched with an Outbound pass-through payment.

11.7.7.1 Matching with Outbound Pass-through Payments

l The classification of gSRP request and Non-gSRP request are done based on the message type and Block 3 fields 111 & 121 as mentioned in section 4.6.3.1

l When the incoming MT n92/gSRP message is not matched with any Inbound Cross Border/RTGS transaction, then the matching is done against Outbound Cross Border/RTGS pass-through payments based on the Inbound SWIFT Payments view tables. Matching criteria used for gSRP request and non-gSRP messages are different

– For gSRP requests, Field 121 UETR of incoming message is matched with the UETR of the Outbound pass-through transaction.

– For non-gSRP MT n92 requests, Field 21 of the incoming message with the Outbound pass-through transaction source reference and sender of the MT n92 request with the Outbound pass-through transaction sender bank field value

l Once the Incoming MT n92/gSRP request message is successfully matched, then system does the below things.

– Process Status value is updated as ‘Matched’ in the Inbound Cancellation Browser.

– Queue action log is populated with action as ‘MATCH’ along with maker/checker ids as SYSTEM and maker/checker timestamps against the Cancellation Request message.

– A recall request record is logged to show under ‘Exception’ screen of outbound Transaction view screen.

l Cancellation processing of an Outbound pass-through transaction is done based on its transaction status and current queue

11.7.7.2 Processed Payments

Transaction Status – Processed / Cancelled / Seized

l If the transaction status is in any of the above listed statuses, then

– Incoming Cancellation request process status in the Inbound Cancellation Browser is updated as ‘Rejected’

11.7.7.3 Unprocessed Payments

Transaction in STP Queue

If the transaction status is in STP Queue, then the system waits for the auto cover match to happen (or) for the manual user action.

Transaction Status – Future Valued

l If the transaction status is ‘Future Valued’ – in ‘Warehouse Queue’, then.

– Recall Status at transaction is updated as ‘Recall Requested’

– Process Status at Inbound Cancellation Browser is updated as ‘Transaction Locked’

– Transaction is moved of the Future Valued queue and

– Transaction is moved to the Inbound Cancellation Request queue

– Transaction Status is updated as the ‘Future Valued’, last queue code as ‘FV’ and Current status as ‘Pending’ in the Inbound Cancellation Request queue

– Queue action is logged for transaction moving out of the Future Dated and for moving to Inbound Cancellation Request queue.

Transaction Status – Exception / In Progress

l If the transaction status is ‘Exception’, then whether the transaction is in an Internal queue (or) not is checked.

l If the transaction is in an Internal exception queue and the last queue action authorization status is ‘Authorized’, then the following actions are taken on the transaction

– Recall Status at transaction is updated as ‘Recall Requested’

– Process Status at Inbound Cancellation Browser is updated as ‘Transaction Locked’

– Transaction is moved of the internal queue and is moved to the Inbound Cancellation Request queue

– Transaction Status is updated as ‘Exception’, last queue code as the Internal queue code and Current status as ‘Pending’ in the Inbound Cancellation Request queue

– Queue action is logged for transaction moving out of the internal queue and for moving to Inbound Cancellation Request queue

List of internal queues considered are

– Settlement Review

– Transaction Repair

– Processing Exception

– Business Override

– Authorization Limit 1

– Authorization Limit 2

– Processing Cutoff

– Network Cutoff

l If the transaction is in an Internal exception queue and the last queue action authorization status is ‘Unauthorized’, then based on the user action cancellation processing happens

List of internal queues that will be considered as follows

– Settlement Review

– Transaction Repair

– Processing Exception

– Business Override

– Processing Cutoff

– Network Cutoff

l If the transaction is in any external queue, then the cancellation processing is done once the transaction is out of the external queue

l The cancellation request check introduced in key processing steps of outbound transaction processing does cancellation processing as mentioned below

l In the external queues, the ‘Carry Forward’ action is not allowed if a cancellation request is found for a transaction

11.7.8 Inbound Pass-through Cancellation Request - Response Processing

Based on the user action selected in Inbound Cancellation Request queue and on the transaction status/last queue code/action combination, the Cancellation Response processing is done.

11.7.8.1 Cancellation Response Processing

Interim Response

On authorization of the Interim action, the system does the below listed processing steps

l A gSRP Response message is generated if the recall request is a gSRP request message. Otherwise, a non-gSRP MT n96 response message is generated.

l A Recall response is logged to show in the Outbound Transaction view – Under Exception – screen

l Queue action is logged for the Interim action against the transaction reference

Accept

On authorization of the Accept action, the following changes are done

l A gSRP Response message is generated if the recall request is a gSRP request message. Otherwise, a non-gSRP MT n96 response message is generated.

l A gCCT reject response message is generated if the recall request is a gSRP request and last queue code is not blank

l Current Status at Inbound Cancellation queue is updated as ‘Accepted’

l Last Response action at Cancellation browser is updated as ‘Accepted’

l Recall status at transaction is updated as ‘Accepted’.

l Recall response is logged to show in the Outbound Transaction view – Under Exception – screen

l Transaction is moved out of the cancellation request queue

l Queue action is logged for the ‘Accepted’ action at the transaction level

l Cancellation processing for the transaction is initiated if the transaction status is not processed

Reject

On authorization of the Reject action, the following changes are done

l A gSRP Response message if the recall request is a gSRP request message is generated. Otherwise, a non-gSRP MT n96 response message is generated.

l Current Status at Inbound Cancellation queue level is updated as ‘Rejected’

l Last Response action at Cancellation browser is updated as ‘Rejected’

l Recall status at transaction is updated as ‘Rejected’.

l Recall response is logged to show in the Outbound Transaction view – Under Exception – screen

l Transaction is moved out of the queue

l Queue action is logged for the ‘Reject’ action at the transaction level

l If the transaction has not been processed [Last queue code is not blank],

– Transaction is reprocessed same as future valued transaction processing done on the value date. During reprocessing, FX Request will not be resent if Reject action was taken on same day.

– Value date/Activation date is rederived

11.7.8.2 gSRP Response Message

The gSRP message generation logic is same as mentioned in section gSRP Response Message(4.6.4.2)

11.7.8.3 Non - gSRP Response Message

The non-gSRP message generation logic is same as mentioned in section Non-gSRP Response Message(4.6.4.3)

11.7.8.4 Interim gSRP Response Message at EOD

The Interim gSRP response message generation logic is same as mentioned in section Interim gSRP Response Message at EOD (4.6.4.4)

 

11.8 gFIT Processing

11.8.1 Outbound Cross Border/RTGS Transaction Processing

Cross Border/RTGS Transaction Processing for Bank Transfer type transactions.

l The 'gpi Agent' flag is set as 'Yes' when the below conditions met:

– The 'gFIT Enabled' flag is 'Yes' at the SWIFT gpi Host Preference maintenance (PXDGPIPF).

– An entry is available in SWIFT gpi Directory for the default branch BIC (maintained at STDCRBRN) and Transfer Currency combination.

Impact in Bank Transfer message generation MT 202/205 as below:

Block 3 - Field 111

If transaction level 'gpi Agent' flag is 'Yes', then the Field 111 is populated with the service id value ('004') for gFIT service.

Field 57A

For gpi enabled 'Cross Border' payment transactions,

Field 57A is populated even if Account with Institution is same as that of Receiver of outgoing payment message.

Note

For 'RTGS' payment transactions irrespective of gpi enabled or not, population of 57A field is based on the RTGS network guidelines.

 

Field 58A

Field 58 is populated option A. BIC is populated.

Field 21

For pass-through payments, Field 21 is populated with the incoming message Field 21.

This processing is applicable for both originated as well as for pass-through outbound bank transfer transactions.

11.8.2 Inbound gFIT Confirmation Message Processing

Incoming MT 299 message is identified as a gFIT confirmation message if the Block 3 - Field 111 is present with a value '004'.

Once the Incoming MT 299 message is identified as gFIT confirmation message, then the same is matched against an Outbound bank transfer transaction. Matching criteria is as follows:

l Block 3 - Field 121: UETR of Incoming MT 299 gFIT confirmation = UETR of Outbound Bank Transfer transaction.

Once the matching is successful, the Inbound confirmation message is parsed and populated in gFIT confirmation table to show in 'Tracker Confirmations' - gFIT Confirmations section.

All received gFIT confirmation message is shown in the Inbound gpi Confirmations Summary (PXSIGPCN) screen with the matched status and the matched transaction reference (if matched).

l If the matching is unsuccessful, the 'Confirmation For' field is populated with a value 'Beneficiary Institution'

l If the matching is successful, the 'Confirmation For' field is populated with a value 'Instructed Agent'

Impact on gCCT/gCOV Confirmation Message Processing

If the Inbound gCCT/gCOV confirmation message is matched against an Outbound transaction, the 'Confirmation For' field value is populated with a value 'Instructed Agent'.

11.8.3 Inbound gFIT Message Processing

Incoming MT 202/205 message is identified as a gFIT payment message if the Block 3 - Field 111 is present with a value '004'.

After receiving a message and after creating an Inbound (or) an Outbound pass-through Bank Transfer transaction, the 'Incoming gpi' flag is marked as Yes if the Incoming MT 202/205 message is identified as gFIT message.

11.9 SWIFT gLowValue Transactions

11.9.1 Outbound Cross Border gLowValue Payment Transaction Input

You can invoke the ‘Outbound Cross Border gLowValue Payment Transaction Input Detailed’ screen by typing ‘PXDOGSOL’ in the field at the top right corner of the application toolbar and clicking the adjoining arrow button. Click ’New’ button on the Application toolbar.

Specify the following details.

Transaction Branch Code

Defaults and displays the current branch of the logged in user.

Branch Name

System defaults the transaction branch Name.

Host Code

Defaults and displays the host code of the logged in user.

Host Code Description

System defaults the description of the host code

Source Code

Specify the Source Code, via which the transaction is to be booked. You can select the Source code from the list of values. All valid source codes are listed.

Source Code Description

System defaults the description of the Source code selected

Transaction Reference Number

System displays auto-generated Transaction reference number. For more details on the format, refer the Payments Core User Guide.

Note

If the Accounting and Message preference in PMDSORCE is opted as Transaction Ref­erence, then the data displayed on this field is populated in Field 20 of the SWIFT mes­sage generated on this transaction.

 

Related Reference Number

On clicking ‘New’, this field will be blank. You can specify the reference number manually, if required.

Source Reference Number

On clicking ‘New’, this field will be blank. You can specify the Source Reference Number manually.

Note

If the Accounting & Message preference in PMDSORCE is opted as Source Reference, then the data input on this field is populated in Field 20 of the SWIFT message generated on this transaction. If no data is input on this field, then Transaction Reference Number of this transaction is populated in Field 20.

 

Network Code

You can select the Cross Border Payments network from the list of values available. All valid Cross border & RTGS networks are listed.

Network Code Description

System defaults the description of the Network Code selected.

gpi UETR

Specify the UETR for the pass-through transaction.

11.9.1.1 Main Tab

Click the Main tab in the ‘Cross Border Outbound Transaction Input’ screen.

Specify the following details:

Payment Details

Booking Date

Booking date is read only field defaulted as the current logged in branch date.

Instruction Date

Select the customer advised Value Date of the transaction using the adjoining calender widget.

Activation Date

System retains the Activation Date input by the user. Also,.Activation date will be an optional field. If the activation date is not provided, system will derive the same

Activation Date is calculated in the following way

l The required number of days are present between activation date and instruction date taking into consideration the settlement days, float days and holidays

l Activation date is not a back date

l Activation Date is not a branch holiday

You can correct the dates and retry, if the entered validation fails. Error message id displayed for the same.

Note

Future dated Cross Border transaction will be processed on the booking date if activation date derived post deducting currency settlement days is current date.

l If the payment request is received through web services, system will re-derive the activation date and will proceed with the payment.

l If the transaction is moved to Network cut off queue, it is possible to provide Activation Date and Instruction date while performing Carry Forward action.

l The’ Value Date change’ action from Future Valued Queue allows providing a new Activation date & Instruction date

l For cross border transactions on Force release with a new instruction date, messages will be generated with new instruction date in field 32A.

 

Transfer Currency

Specify the currency in which the payment needs to be made. Alternatively, you can select the currency from the option list. The list displays all valid currencies maintained in the system.

Note

l If Transfer Currency is specified as CNH in an outbound transaction, then system will check whether CNH Conversion is required at host level.

l If CNH Conversion is maintained as yes in PXDCNHCN, then transaction is created with the currency as CNH. In the Outgoing message generated, the transfer currency is converted to CNY.

l If CNH Conversion is maintained as No in PXDCNHCN, transaction is processed and message is generated with CNH currency as per current functionality.

 

Transfer Amount

You can input Transfer amount, if Instructed currency indicator is Transfer Currency. If it is Debit currency, then the transfer amount is derived based on the  Debit amount and Transfer currency applying exchange rate.

Debit Account

Specify the debit account of the transaction. Alternatively, you can select the debit account from the option list. The list displays all valid accounts maintained in the system.

Debtor Name

System defaults the Name on selecting the Debit Account.

Debit Account Currency

The system displays the debit account currency based on the debit account selected. In case of Prefunded payment, where Debit happens on a GL, Debit Account Currency is considered same as Transfer Currency. In case if Debtor Account selected is a GL account, you can specify it from the list of values.

Debit Currency Name

System defaults account currency name based on the debit account number selected.

Debit Amount

Specify the Debit Amount for the transaction, if Instructed Currency Indicator is selected as Debit Currency. If it is selected as Transfer Currency, then this field is disabled and derived based on the Transfer currency, amount & Debit account currency.

Exchange Rate

The exchange rate is applicable for cross-currency transactions. The transaction is considered as cross-currency transaction if for an Outbound payment the debit account currency is different from the transfer currency.

FX Reference Number

Specify the foreign exchange reference.

Customer Number

The system defaults the Customer Number of the Debit Account selected.

Customer Service Model

The system defaults the Customer Number of the Debit Account selected.

SSI Label

Select the required SSI label from the list of values. Valid SSI labels for the debit customer, network and currency is listed in the list of values.

Remarks

Specify any Operations remark or additional info pertaining to this transaction.

Note

On Outgoing Cross Border Transaction liquidation, Debit Advice is generated as per cur­rent advice framework, to the debtor, Advice tag '_REMARKS_' for Remark is available in the generated mail advice.

 

Debit Entry on

Select the Debit entry posting date preference from below options:

l On Activation Date

l On Value Date

Credit Entry on

Select the Credit entry posting date preference from below options:

l On Activation Date

l On Value Date

Enrich Button

Click on Enrich button upon providing the Payment details and the valid account number/Payment Identifier based on the Transfer Type selected. This is mandatory.

System defaults the debit/credit account details and payment chain building in the respective fields, based on the data entered.

Note

This list is populated with valid SSI Labels, applicable for the customer and the Network. If Customer or Network details are not available, the fetch action of the list of values dis­plays the information message to this effect. The list of values is queried based on the fields SSI Label, Beneficiary Bank ID, Beneficiary Account & Account IBAN

If a valid Customer Preference maintenance (open & authorized) is found, then the Pricing account, Pricing account's currency and Pricing account's branch gets defaulted into Charge Account Number, Charge Account currency and Charge Account Branch respec­tively.

Charge account defaulting is done only if the Charge Account number is not provided by user at the time of clicking Enrich button.

 

Credit Account Details

Credit Account

Specify the credit account of the transaction. Alternatively, you can select the Credit account from the option list. The list displays all valid accounts maintained in the system.

Creditor Name

System defaults the Name on selecting the Credit Account.

Credit Account Currency

The system displays the credit account currency based on the credit account selected.

Credit Currency Name

System defaults account currency name based on the credit account number selected.

Credit Value Date

Credit Value Date is derived and displayed on clicking Enrich button. This is same as the Instruction date.

Debit Value Date

Debit Value Date is derived and displayed on clicking Enrich button. Activation Date is defaulted in this field, if Debit value date option at Network Preference is set as Activation Date. If the preference is Instruction date, then the Instruction date input above is copied on to this field.

Message Date

For Outbound transactions, the system computes the message date based on the credit value date and displays it here along with the cut-off time.

50: Ordering Customer

Party Identifier

Specify the party identifier details.

BIC / Name and Address 1

Select the BIC from the LOV.

BIC Code Description

Select the BIC from the LOV.

Name and Address 2 - 4

Specify the name and address of the Beneficiary Institution in the lines specified.

59: Ultimate Beneficiary

Account

Specify the Ultimate Beneficiary Account Number.

BIC / Name and Address 1

Select the BIC from the LOV.

BIC Code Description

Select the BIC from the LOV.

Name and Address 2 - 4

Specify the name and address of the Ultimate Beneficiary in the lines specified.

Country

Select the country from the LOV.

56: Intermediary Bank

Party Identifier

Specify the Party identifier details.

Bank Identifier Code

Select the BIC from the LOV.

BIC Code Description

Select the BIC from the LOV.

57: Account With Institution

Party Identifier

Specify the Party identifier details.

Bank Identifier Code

Select the BIC from the LOV.

BIC Code Description

Select the BIC from the LOV.

70: Remittance Information

Remittance Information 1- 4

You can enter the sender to receiver details.

Note

– The beneficiary details related fields in the main screen are disabled for input if the network selected is of payment type SWIFT/RTGS.

– If the Receiver provided in SSI label is not a currency correspondent, then cover is sent to default currency correspondent.

– Field 58 Beneficiary institution details can be specified only if the customer selected is of type ‘Bank’.

– If Receiver correspondent is part of SSI label, then it is mandatory to provide Nostro Credit account details in the SSI label maintenance.

 

Receiver Details

Receiver

System derives the Receiver (bank) of the Outbound payment message as part of Payment chain building activity and populates the BIC code of this bank in this field.

This field is also populated on clicking Enrich button.

You may choose to override the system derived Receiver with a different BIC code and input the same over here. On save, system validates if a SWIFT message can be sent to the user specified Receiver BIC code.

Receiver Description

System defaults the description of the Receiver selected.

11.9.1.2 Pricing Tab

You can view the charge amount computed by the system for each of the Pricing components of the Pricing code linked to the network code of the transaction. Click the “Pricing” tab.

For the Transaction initiated, system displays the fees/tax charged in this section.

Pricing Component

The system displays each Pricing component of the Pricing code from the Pricing Code maintenance.

Pricing Currency

The system displays the Pricing currency of each Pricing component of the Pricing code.

Pricing Amount

The system displays the calculated Charge amount for each Pricing component of the Pricing code.

Waived

The system displays if charges for any Pricing component are waived in the Pricing maintenance.

Debit Currency

The system displays the currency of the Charge account to be debited for the charges.

Debit Amount

The system displays the Charge amount for each Pricing component debited to the charge account in Debit currency. If the Pricing currency is different from the Debit currency the calculated charges are converted to the Debit currency and populated in this field.

11.9.1.3 UDF Tab

Click the ‘UDF’ Section in the Transaction View screen to invoke this sub screen.

This sub-screen defaults values of UDF fields that are part of the UDF group specified for the ‘Manual’ source.

Specify the following details.

Fields

Field Label

The system displays all fields that are part of the associated UDF group.

Value

The system displays the default value, where exists for the UDF fields. You can change the default value or specify value for other fields (where default value does not exist)

11.9.1.4 MIS Tab

You can maintain the MIS information for the Transaction. If the MIS details are not entered for the Transaction the same is defaulted from the product maintenance. Click the ‘MIS’ tab to invoke the ‘MIS’ sub-screen

Specify the following details

Transaction Reference

The system displays the transaction reference number of the transaction.

MIS Group

Specify the MIS group code. Alternatively, you can select the MIS group code from the option list. The list MIS group displays all valid MIS groups maintained in the system for different sources in the Source maintenance. By default, the MIS group linked to the ‘Manual’ source is populated while booking a transaction from this screen.

Default button

Click this button after selecting a MIS group different from the default MIS Group (which was populated) so that any default MIS values can be populated from to link to the Transaction MIS and Composite MIS classes.

Transaction MIS

The default MIS values for Transaction MIS classes are populated for the MIS group. You can change one or more default MIS values or specify more MIS values. Alternatively, you can select MIS values from the option list.

Composite MIS

The default MIS values for Composite MIS classes are populated for the MIS group. You can change one or more default MIS values or specify more MIS values. Alternatively, you can select MIS values from the option list.

11.9.1.5 Messaging and Accounting Entries

You can invoke the “Messaging Details” screen by clicking the “Messaging Details” tab in the Message and Accounting Entries  sub screen

Specify the Transaction Reference Number and click on Execute Query to obtain the Message details

By default, the following attributes of the Message Details tab are displayed.

l DCN

l Message Type

l SWIFT Message Type

l Message Status

l Direction

l Message Date

l Authorization Status

l Acknowledgement Status

l Media

l Receiver or Sender

l PDE Flag

l Suppressed

Following Message details are also displayed on clicking Execute Query button

l DCN

l Message Type

l SWIFT Message Type

l Message Status

l Message

You can invoke the “Accounting Entries” tab by clicking the “Accounting Entries” tab in the Message and Accounting Entries sub screen

Specify the Transaction Reference Number, Transaction Status, Queue Code and click on Execute Query to obtain the Message details.

By default, the following attributes of the Accounting Entries tab are displayed.

l Event Code

l Transaction Date

l Value Date

l Account

l Account Branch

l TRN Code

l Dr/Cr

l Amount Tag

l Account Currency

l Transaction Amount

l Netting

l Offset Account

l Offset Account Branch

l Offset TRN Code

l Offset Amount Tag

l Offset Currency

l Offset Amount

l Offset Netting

l Handoff Status

11.9.1.6 Payment Chain

You can view the Payment Chain details for the transaction  in this screen. Click the “Payment Chain” link in the Transaction Input screen to invoke this sub-screen

Displays the following details.

Chain Order

Specifies the order of banks/institutions in the payment chain

Bank Code

The system displays the BIC code of the bank/institution.

RMA/RMA Plus

The system displays if Sending bank has RMA/RMA Plus maintenance with the particular bank in the payment chain.

Account Number

The system displays the Nostro (mirror) /Vostro account number associated with the particular bank.

Field Number

The system displays the field number used internally to identify the position of the party in the Outbound SWIFT message. E.g “53” corresponds to field 53 in SWIFT message whereas “02” is used to identify the Receiver of the message

11.9.1.7 Outbound Cross Border gLowValue Payment Transaction Input Summary

You can invoke “Outbound Cross Border gLowValue Payment Transaction Input Summary” screen by typing ‘PXSOGSOL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters.

l Transaction Reference Number

l Multi Credit Reference Number

l Source Reference Number

l Related Reference Number

l Network Code

l Source Code

l Authorization Status

l Template ID

l Booking Date

l Instruction Date

l Activation Date

l Transfer Currency

l Transaction Amount

l Transfer Type

l Maker ID

l Checker ID

l Branch Code

l Debit Account No

l Customer Number

l Customer Service Model

l Receiver BIC

l Account With Institution BIC

l Banking Priority

l gpi Agent

11.9.2 SWIFT gLowValue Payment Host Preferences

You can invoke ‘SWIFT gLowValue Payment Host Preferences Detailed’ screen by typing ‘PXDGPSPF’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can specify the following details:

Host Code

System defaults the Host code of the selected branch on clicking ‘New’ button.

Host Code Description

System defaults the Description of the Host Code displayed.

Transfer Currency

Specify the Transfer Currency from the list of values. This field represents both transfer currency and limit currency.

Limit Amount

Specify the Maximum transfer amount allowed per currency.

11.9.2.1 SWIFT gLowValue Payment Host Preferences Summary

You can invoke ‘SWIFT gLowValue Payment Host Preferences Summary’ screen by typing ‘PXSGPSPF’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Authorization Status

l Record Status

l Host Code

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

11.9.3 Inbound Cross Border gLowValue Payment Processing

l The inbound cross border gLowValue payment processor performs following gLowValue Payment specific processing steps and validations.

l In case of any validation failure at STP layer, system moves the transaction to Process Exception queue of STP Layer and mark it as Exception . You can view the transaction from PSSIVIEW.

11.9.3.1 Incoming gpi & gpi Payment Type Check

l If an incoming payment (MT 103) has gpi tags (111:009):

– gpi Payment Type’ field set to 'gLowValue'. ‘gpi Payment Type’ is resolved as follows:

– If the incoming gpi flag is set to ‘Y’. There are no further processing validations based on the ‘incoming gpi’ check for gLowValue payments.

l If Field 111 does not have gpi tags, ‘gpi Payment Type’ remain ‘blank’.

11.9.3.2 Host Level Check

If 'gpi Payment Type' is 'gLowValue', the system performs the following steps:

l The system checks for the record at the 'SWIFT gLowValue Payment Host Preferences' (PXDGPSPF) screen. If no record exists, the system moves the transaction to Process Exception queue with the error message “gLowValue Payment Preferences are not maintained”.

l The system checks for transfer currency. If no record is found for the transfer currency (only USD/GBP/EUR), it moves the transaction to the Process Exception queue with the error message “gLowValue Payment transfer currency is not maintained”.

l The system skips the above condition if transfer amount is within the allowed limit per currency or not at host level.

11.9.3.3 gpi Agent check

l If 'gpi Payment Type' is 'gLowValue':

– Set 'gpi agent' to 'Yes'. If processing branch BIC, Transfer Ccy, gpi service id 009 combination is found in gpi directory.

– Set 'gpi agent' to 'No'. If no record found for the above combination, the system moves the transaction to Process Exception queue.

11.9.3.4 Cover Matching

l Cover Matching and Inbound Messages STP queues (PQSSTPQU)/ conditions are not applicable, since MT103 Simple does not have field 53A,54A,55A.

l If the debit nostro account is not found for the sender BIC, system moves the transaction to Repair Queue, as per current support.

11.9.3.5 Network Cutoff Check

If ‘gpi Payment Type’ is ‘gLowValue’, the system performs the below steps for the network cutoff check:

l Network cutoff check based on Inbound gpi Payment Sender Agreement from the screen (PXDSRIAG) will be skipped for Sender BIC (11-Character BIC as received in Block 2 of the incoming MT message).

l The system checks if the Processing branch BIC (11-Character BIC as received in Block1 of the incoming MT message), Transfer Currency, gpi service id ‘009’ combination is present in gpi Directory (PMDGPIDR).

l If not found in the above step, the system checks if Processing branch BIC (11-Character BIC maintained as default BIC in STDCRBRN), Transfer Currency, gpi service id ‘009’ combination is present in gpi Directory.

l If found and the ‘gLowValue Payment’ transaction passed this cut-off time, then the transaction moves to the Network Cutoff.

11.9.3.6 Pricing

l If ‘gpi Payment Type’ is ‘gLowValue’, the system skips the Pricing Computation (Internal/External). However, the system parses the 71A value as received (SHA) in the incoming payment for the ‘charge whom’ option (PXDIVIEW).

11.9.3.7 Generate gLowValue Payment confirmations

l If 'gpi Payment Type' is 'gLowValue':

– The system generates MT199 (FIN) with gLowValue Payment service id '009' in field 111 of Block 3 or API confirmations (as applicable).

– RMA+ validation for Tracker BIC is not done.

– There are no Sanctions Check validation done for the gpi Confirmation messages.

– The system populates 71F as '0' in the repetitive lines of gLowValue Payment confirmations (after Line 1-5).

//:71F:USD0,

//:71F:USD0,

Note

71F : (currency)(amount)

For 'currency' part, the system use 32A currency (transfer currency)

 

 

11.9.4 Outbound gLowValue Payment Processing

The outbound cross border gLowValue payment processor performs following gLowValue Payment specific processing steps and validations:

11.9.4.1 Pricing

If 'gpi Payment Type' is 'gLowValue', the system skips the Pricing Computation (Internal/External).

 

11.9.5 Outbound Pass Through gLowValue Payment Processing

l The outbound pass-through cross border gLowValue payment processor performs following gLowValue Payment specific processing steps and validations.

l In case of any validation failure at STP layer, system moves the transaction to Process Exception queue of STP Layer and mark it as Exception . You can view the transaction from PSSIVIEW.

11.9.5.1 Incoming gpi & gpi Payment Type Check

l If an incoming payment (MT 103) has gpi tags (111:009):

– gpi Payment Type’ field set to 'gLowValue'. ‘gpi Payment Type’ is resolved as follows:

– If the incoming gpi flag is set to ‘Y’. There are no further processing validations based on the ‘incoming gpi’ check for gLowValue payments.

l If Field 111 does not have gpi tags, ‘gpi Payment Type’ remain ‘blank’.

11.9.5.2 Host Level Check

If 'gpi Payment Type' is 'gLowValue', the system performs the following steps:

l The system checks for the record at the 'SWIFT gLowValue Payment Host Preferences' (PXDGPSPF) screen. If no record exists, the system moves the transaction to Process Exception queue with the error message “gLowValue Payment Preferences are not maintained”.

l The system checks for transfer currency. If no record is found for the transfer currency (only USD/GBP/EUR), it moves the transaction to the Process Exception queue with the error message “gLowValue Payment transfer currency is not maintained”.

l The system skips the above condition if transfer amount is within the allowed limit per currency or not at host level.

11.9.5.3 gpi Agent check

l If 'gpi Payment Type' is 'gLowValue':

– Set 'gpi agent' to 'Yes'. If processing branch BIC, Transfer Ccy, gpi service id 009 combination is found in gpi directory.

– Set 'gpi agent' to 'No'. If no record found for the above combination, the system moves the transaction to Process Exception queue.

11.9.5.4 Payment Chain Lookup

l If ‘gpi Payment Type’ is ‘gLowValue’, the system look up the payment chain.

l There is no change to the original parties as received in the incoming MT103. Payment is passed without altering original payment parties [BICs].

11.9.5.5 Network Cutoff Check

If ‘gpi Payment Type’ is ‘gLowValue’, the system performs the below steps for the network cutoff check:

l Network cutoff check based on Outbound gpi Payment Receiver Agreement from the screen (PXDSROAG) is skipped for Receiver BIC, even if receiver BIC is identified as gLowValue Payment agent based on gpi directory (BIC/CCY/gpi service id '009' combination).

l Cutoff time is taken from gpi directory (PMDGPIDR).

l If not found in gpi directory, the system process the payment as applicable for normal outgoing SWIFT payments (PXDCYCOF)

l The system takes Cutoff time from network maintenance (PMDNWMNT) for FIN RTGS (TARGET 2, EURO1) payments, as per existing support.

11.9.5.6 Pricing

l If ‘gpi Payment Type’ is ‘gLowValue’, the system skips the Pricing Computation (Internal/External). The system parses the 71A value as received (SHA) in the incoming payment for the ‘charge whom’ option (PXDOVIEW) and also generate MT103 gLowValue Payment message with Field as 71A:SHA.   .

11.9.5.7 Field 71F

If 'gpi Payment Type' is 'gLowValue', The system populates Field 71F as '0' in the outbound pass-through MT103 gLowValue Payment message generated.

Note

71F : (currency)(amount)

For 'currency' part, the system use 32A currency (transfer currency)

 

11.9.5.8 Generate gLowValue Payment confirmations

l If 'gpi Payment Type' is 'gLowValue':

– The system generates MT199 (FIN) with gLowValue Payment service id '009' in field 111 of Block 3 or API confirmations (as applicable).

– RMA+ validation for Tracker BIC is not done.

– There are no Sanctions Check validation done for the gpi Confirmation messages.

– The system populates 71F as '0' in the repetitive lines of gLowValue Payment confirmations (after Line 1-5).

//:71F:USD0,

//:71F:USD0,

11.9.5.9 Field 23B, 23E

l If 'gpi Payment Type' is 'gLowValue':

– Field 23B (Bank operation code) with default value 'CRED' get added in pass-thru MT103 gLowValue Payment message generated.

– Field 23E (Instruction Code) is not added/present in pass-thru MT103 gLowValue Payment message generated.

11.9.5.10 Field 52A, 57A, 72

l If 'gpi Payment Type' is 'gLowValue':

– Field 52A (Ordering Institution) get populated in the pass-thru outbound MT103 simple message generated.

– Field 57A get populated even if Account with Institution is same as that of Receiver of pass-thru outbound payment message.

– Field 72 is not added in pass-thru MT103 gLowValue Payment message generated.

11.10 SWIFT gpi Tracker API services

OBPM supports below SWIFT gpi Tracker API services Version 5.x:

l Status Confirmations: Payment Transactions - Updating the Status of a Payment Transaction Purpose of the API

l Transaction cancellation request (gSRP request).

l Transaction cancellation response (gSRP response) status update for incoming gSRP cancellation requests

l SWIFT gpi Status Reading via API

l gpi Tracker Enquiry by UETR

l No support for previous API versions

 

11.11 SWIFT gpi Status Reading via API

11.11.1 SWIFT gpi Status Reading via API

You can capture the preferences like enquiry frequency, start time, end time and type of the payment scenario to be sent in the gpi Changed Payment Transactions enquiry API.

You can invoke ‘SWIFT gpi Status Reading via API Detailed’ screen by typing ‘PXDGPEPF’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can specify the following details:

Host Code

System defaults the Host code of the selected branch on clicking ‘New’ button.

Enquiry Type

Select the Enquiry Type from following list:

l ALL

l gCCT

l gCOV

l gFIT

l gSRP

Enquiry Frequency

Specify the Frequency of querying the Tracker for getting latest statuses. Frequency is given in minutes. The Minimum value specified can be 30 and Maximum value can be 300. Specify the Value in multiple of 30.

Start Time

Specify the Start time of the day when the first enquiry to gpi Tracker to be made for a day.

End Time

Specify the End time of the day when the last enquiry to gpi Tracker to be made for a day.

Last Run Date

Last Run Date is displayed.

Last Run Time

Last Run Time is displayed.

11.11.1.1 SWIFT gpi Status Reading via API Summary

You can invoke ‘SWIFT gpi Status Reading via API Summary’ screen by typing ‘PXSGPEPF’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Authorization Status

l Record Status

l Host Code

l Enquiry Type

l Enquiry Frequency

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

11.11.2 SWIFT gpi API Tracker Status Browser

You can view the requests that are generated/sent out and responses received from SWIFT gpi Tracker.

You can invoke ‘SWIFT gpi API Tracker Status Browser’ screen by typing ‘PXSGPTRB’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search using one or more of the following parameters:

l Enquiry Reference Number

l Status

l Enquiry Date

l Enquiry Type

l Run Type

Once you have specified the search parameters, click ‘Search’ button. The system displays the records that match the search criteria.

You can perform the following action:

11.11.2.1 View Message

On clicking of this button, ‘SWIFT gpi API Tracker Status Enquiry -Messages’ sub screen is displayed, with multi record block that displays all the sub requests that are part of the main request.

Below are the actions on this sub screen:

View Request

On clicking of the button, a sub screen is displayed that displays the request JSON message generated and sent out.

API Response Status Button

Click on ‘API Response Status’ button, to View API Response Status screen for status enquiry message that was generated and sent out.

The system displays the following details

DCN

The system displays Document Number value of the API message.

Response Status

This field displays value as ‘Success’ or ‘Failure’.

Response Code

This field displays HTTP Response code.

Error

This field displays HTTP Error message.

View Response

On clicking of the button, a sub screen is displayed that displays the response JSON message received from Tracker.

11.11.2.2 View Response

On clicking of this button, ‘SWIFT gpi Tracker Status Enquiry - Responses’ sub screen is displayed. This screen has a multi record block and displays the parsed response messages.

 

 

11.11.2.3 Ad-hoc Request

On clicking of this button, ‘SWIFT gpi API Tracker Status Enquiry -Adhoc Request’ sub screen is displayed.

Below are the action on this sub screen:

Ad-hoc Request

On clicking of the 'Ad-hoc Request' button, the Tracker Changed Payment Transactions API request message is generated, and the API call is made.

The request is logged into the status enquiry log table and the status is marked as 'In Progress'. Once the response is received, the status is marked as 'Processed' if all the pages are read successfully. The status is marked as 'Failed' if there is a negative response.

View Message

On clicking of 'View Message' action, the ‘SWIFT gpi API Tracker Status Enquiry -Messages’ sub screen is displayed.

 

11.12 gpi Tracker Enquiry by UETR

11.12.1 gpi Tracker Enquiry by UETR

You can invoke ‘gpi Tracker Enquiry by UETR’ screen by typing ‘PXDGPIEN’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

If this screen is launched from the Outbound Cross Border/RTGS Transaction View Summary screen (PXSOVIEW), then the below fields are populated with the values of the selected Outbound Cross border/RTGS transaction:

l UETR

l Enquiry Reference Number

l Transaction Reference

l Enquiry Source Reference

l Source Reference

l Enquiry Source

l Transaction Type

l Account

l Confirmation Status

l Status Description

l Status Reason

l Reason Description

l Cancellation Status

l Cancellation Status Description

A reference number (16 digit) gets generated and populated as Enquiry reference Number. The enquiry request message gets framed and sent to the Tracker. The response received from the Tracker is parsed and selected information is displayed in this screen.

If this screen is launched from the application menu, then you can specify the UETR. Below validations will be done on this field.

l Format of this field should be xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where x is any hexadecimal character (lower case only) and y is one of 8, 9, a, or b.

l UETR should not be the UETR value of any Outbound/Inbound Cross Border/RTGS transactions.

Enquiry Request

On clicking of Enquiry Request, the enquiry reference (16 digit) gets generated and then enquiry request message gets framed or is sent to the Tracker. The response received from the Tracker is parsed and selected information is displayed in this screen.

API Response Status Button

Click on ‘API Response Status’ button, to View API Response Status screen for UETR enquiry message that was generated and sent out.

The system displays the following details

DCN

The system displays Document Number value of the API message.

Response Status

This field displays value as ‘Success’ or ‘Failure’.

Response Code

This field displays HTTP Response code.

Error

This field displays HTTP Error message.

11.12.1.1 Transaction Type Processing

l The system performs the below validation for the transaction type 'Outbound':

– UETR value is present in one of the outbound transactions.

– The source of the outbound transaction is the same as the source value given in the service request.

– The debit account of the original transaction is the same as the account given in the service request.

– In case any of the above-listed validations fail, then the Enquiry Service request gets rejected and an error code/description is sent in the response.

l The system performs the below validation for the transaction type 'Inbound':

– UETR length is 36 characters and as per for the UETR format ([a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89ab][a-f0-9]{3}-[a-f0-9]{12}).

– UETR value is not present in one of the outbound transactions.

– UETR value is not present in one of the Inbound transactions.

– In case any of the validations fail, the Enquiry request gets rejected.

l In the received response, the system looks for the below-listed data:

– Any payment event record with Tracker Event Type as ‘CTPT’.

– In the ‘CTPT’ event type record, the Creditor Account value is present.

l If Creditor Account value is present, the system performs below listed validations:

– Creditor Account IBAN value is not blank and the IBAN value is the same as IBAN of the Account Number given in the request (or) Creditor Account Identification value is not blank and the value is same as the Account Number given in the request.

l If any of the above validations fail, then the response to the enquiry request from the channel shows an error code/error description.

l After successful validations of the gpi Tracker API response, Oracle Banking Payments frame the response message to be sent to the channels.