0% found this document useful (0 votes)
28 views

Exception_Queues

Uploaded by

ARYAN AGRAHARI
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
28 views

Exception_Queues

Uploaded by

ARYAN AGRAHARI
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 119

Exception Queues User Guide

Oracle Banking Payments


Release 14.4.0.0.0

Part No. F31489-01

October 2021
Exception Queues User Guide
Oracle Financial Services Software Limited

Oracle Park

Off Western Express Highway


Goregaon (East)
Mumbai, Maharashtra 400 063
India
Worldwide Inquiries:
Phone: +91 22 6718 3000
Fax: +91 22 6718 3001
www.oracle.com/financialservices/

Copyright © 2017, 2021, Oracle and/or its affiliates. All rights reserved.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs
installed on the hardware, and/or documentation, delivered to U.S. Government end users are “commercial computer software”
pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use,
duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any
programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable
to the programs. No other rights are granted to the U.S. Government.

This software or hardware is developed for general use in a variety of information management applications. It is not developed
or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If
you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate failsafe,
backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for
any damages caused by use of this software or hardware in dangerous applications.

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure
and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you
may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish or display any
part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by
law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors,
please report them to us in writing.

This software or hardware and documentation may provide access to or information on content, products and services from
third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with
respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss,
costs, or damages incurred due to your access to or use of third-party content, products, or services.

1-1
Contents

1. About this Manual .................................................................................... 1-1


1.1 Introduction.............................................................................................................. 1-1
1.2 Audience.................................................................................................................. 1-1
1.3 Documentation Accessibility.................................................................................... 1-1
1.4 Organization ............................................................................................................ 1-1
1.5 Glossary of Icons..................................................................................................... 1-2
2. Exception and Investigation Queues ..................................................... 2-1
2.1 Payment Queues..................................................................................................... 2-2
2.1.1 Repair Queue ............................................................................................. 2-2
2.1.2 Business Override Queue .......................................................................... 2-8
2.1.3 Process Exception Queue ........................................................................ 2-11
2.1.4 Authorization Limit 1 Queue ..................................................................... 2-13
2.1.5 Authorization Limit 2 Queue ..................................................................... 2-15
2.1.6 Processing Cutoff Queue ......................................................................... 2-17
2.1.7 Settlement Review Queue........................................................................ 2-19
2.1.8 EU Payer Compliance Queue .................................................................. 2-23
2.1.9 Sanctions Queue ...................................................................................... 2-28
2.1.10 Exchange Rate Queue ............................................................................. 2-31
2.1.11 FX Unwind Queue .................................................................................... 2-34
2.1.12 External Pricing Queue............................................................................. 2-36
2.1.13 External Account Check Queue ............................................................... 2-37
2.1.14 External Credit Approval Queue............................................................... 2-40
2.1.15 Network Cutoff Queue .............................................................................. 2-43
2.1.16 Inbound Messages STP Queue ............................................................... 2-44
2.1.17 Incoming Swift Payment View .................................................................. 2-48
2.1.18 Warehouse Queue ................................................................................... 2-62
2.1.19 Accounting Queue .................................................................................... 2-65
2.1.20 Non STP Queue ...................................................................................... 2-67
2.1.21 Network Resolution Queue....................................................................... 2-70
2.1.22 R Processing Queue ................................................................................ 2-78
2.1.23 Dispatch File Browser............................................................................... 2-79
2.1.24 Outbound Charge Claim Queue ............................................................... 2-85
2.1.25 Inbound Charge Claim Queue.................................................................. 2-88
2.1.26 Inbound Cancellation Request Browser ................................................... 2-91
2.1.27 Inbound Cancellation Request Queue...................................................... 2-96
2.1.28 Inbound Non-gpi n99 Queue ................................................................... 2-99
2.1.29 Incoming Unmatched Queue ................................................................. 2-102
2.1.30 Verification Queue .................................................................................. 2-103
2.2 External Response Exception Log Summary ...................................................... 2-105
2.2.1 Retry Screen........................................................................................... 2-106
2.2.2 View Response Screen .......................................................................... 2-107
2.2.3 Ignore Screen ......................................................................................... 2-107
2.3 Accounting Resend Summary ............................................................................. 2-107
3. Cancellation from Exception Queues .................................................... 3-1
3.1 Cancelling Outbound payment ................................................................................ 3-1
3.2 Cancelling Inbound payment ................................................................................... 3-1
4. Exception and Investigation Queues ..................................................... 4-1
4.1 Acting from an Exception Queue on a later day ...................................................... 4-1
5. Exception Queues - Export Option ........................................................ 5-1
6. Function ID Glossary ............................................................................... 6-1
1. About this Manual
1.1 Introduction
This manual is designed to help you to quickly get familiar with the exception queues and
related queue actions in Oracle Banking Payments.

You can further obtain information specific to a particular field by placing the cursor on the
relevant field and striking <F1> on the keyboard.

1.2 Audience
This manual is intended for the following User/User Roles:

Role Function

Payment Department Operators Payments Transaction Input functions except


Authorization

Back Office Payment Payments related maintenances/Exception queue


Department Operators operations/Payment Transaction Input functions
except Authorization

Payment Department Officers Payments Maintenance/ Transaction Authorization/


Queue action authorization

Bank’s Financial Controller/ Host level processing related setup for PM module
Payment Department Manager and PM Dashboard/Query functions

1.3 Documentation Accessibility


For information about Oracle's commitment to accessibility, visit the Oracle Accessibility
Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

1.4 Organization
This manual is organized into the following chapters:

Chapter Description

Chapter 1 About this Manual gives information on the intended audience. It also
lists the various chapters covered in this User Manual.

Chapter 2 Exception and Investigation Queues - Gives information on payment


queues.

Chapter 3 Function ID Glossary has alphabetical listing of Function/Screen ID's


used in the module with page references for quick navigation.

1-1
1.5 Glossary of Icons
This User Manual may refer to all or some of the following icons:

Icons Function

Exit

Add row

Delete row

Option List

1-2
2. Exception and Investigation Queues
Exception queues are a logical stage of the payment processing where the payments are
made available for further investigation or exception processing. If any exception is
encountered during processing, payment transactions are moved to a queue specific to the
type of exception. Actions that can be performed on a payment that is pending in a queue are
predefined. Transactions with exceptions, pertaining to your logged in Host only are listed in
the Queues.

Below mentioned exception and investigation queues are supported in Oracle Banking
Payments:

S.No Payments Queue Queue Code

1 Repair Queue TR

2 Business Override Queue BO

3 Authorization Limit 1 Queue AL

4 Authorization Limit 2 Queue AL

5 Processing Cutoff Queue PC

6 Sanction Check Queue SC

7 Exchange Rate Queue EE/ER

8 FX Unwind Queue FC

9 EAC Queue EA

10 ECA Queue EC

11 Network Cutoff Queue NC

12 Processing Exception Queue PE

13 Inbound Message STP Queue MC

14 External Pricing Queue EP

15 Settlement Review Queue SI

16 Warehouse Queue FV

17 Accounting Queue AC

18 Network Resolution Queue NW

19 EU Payer Queue EQ

20 R Processing Queue RQ

21 Dispatch Queue DQ

2-1
22 Dispatch Browser DS

23 Template Queue TQ

24 Outbound Charge Claim Queue CO

25 Inbound Charge Claim Queue CI

26 Standing Instruction Queue ST

27 Standing Instruction Execution SE

28 Inbound Cancellation Request Browser CQ

29 Inbound Cancellation Request Queue IR

Note
– Authorization limit queues are not applicable for Direct Debits and Faster Payments.
– Network/Process cutoff queues are not applicable for Direct Debits.

2.1 Payment Queues


2.1.1 Repair Queue

Usage of Repair Queues

A payment is moved to Repair Queue if the exception is a repairable error, as listed below:

Outbound payments
 Payment Chain Failure
 SWIFT related validations failure (F72, F59 length validations, F59 not present)
 IBAN not valid
 Counterparty bank code not available
 Counterparty bank code not valid
 Debit & Credit account are same
 Invalid Receiver BIC
 MIS Codes Invalid

Inbound Payments
 Account Status - Closed / Unauthorized
 Debit / Credit account Resolution failure
 Beneficiary name mismatch
 MIS Code Invalid

You can invoke “Repair Queue” screen by typing ‘PQSREPQU’ in the field at the top right
corner of the Application tool bar and clicking on the adjoining arrow button. Click New button
on the Application toolbar.

2-2
You can search using one or more of the following parameters:
 Queue Reference Number
 Transaction Reference Number
 Network Code
 Queue Status
 Transaction Type
 Transaction Branch
 Transfer Currency
 Transfer Amount
 File Reference Number
 Error Code
 Repair Reason
 Customer Service Model
 Customer Number
 Source Code
 Authorization Status
 Activation Date
 Queue Action
 Source Reference Number
 Company ID
 Batch ID
 Banking Priority
 Verification Status
 Network Type Code

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

The queue records can be sorted out based on the Network cutoff time.Cutoff time is listed as
part of the Queue records.This applicable for all the Payment Types.

Note
For cross-border transactions, the cutoff time is based on the BIC cutoff time applicable.

The following actions can be performed for transactions in Repair queue.

2.1.1.1 Repair Action

This action enables you to modify the payment details and submit for re-processing. On
completion of repair action, transaction is re-processed, starting from initial validations.

Note
You are allowed to modify only those erroneous data due to which, the payment is moved
to repair queue.

You can invoke “Repair Action” screen by clicking on the action button present at bottom of
the ‘Repair Queue ‘screen ‘PQSREPQU’.

On selecting a record in the Repair Queue screen and on clicking Repair Action button, details
pertaining to that Transaction reference are displayed.

Specify the following fields:

Remarks
Specify any remarks, if any against the field that is likely to be repaired. This is a mandatory
field.

2-4
Repaired Data
 Current inputted data is listed in the Old Data field. By default the same is listed on
Repaired Data field as well. You can edit & correct the Repaired Data & repair the
payment.
 If repaired new data is not proper, payment lands in the repair queue again.
 For a cross border payment, landed in repair queue when receiver BIC is unable to
resolve from address details present, new learned record is created in DtoA
(PMDDAMNT) screen on repair.

2.1.1.2 Cancel/Return/Suppress Action

For the details on, processes followed on cancelling a payment, refer to section 3.

2.1.1.3 View Queue Action

Displays all queue activities performed for the selected transaction.

You can invoke “View Queue Action” screen by clicking on the action button present at bottom
of the ‘Repair Queue‘ screen ‘PQSREPQU’.

2.1.1.4 Verify

This sub screen is launched if:


 You have the required Role/User Level access right for the User Action 'Verify'.
 Queue authorization status is 'Authorized', and Verification Status is 'Unauthorized'.
 If the 'Dual Authorization' is checked and if the derived Threshold amount is above the
Threshold Amount maintained in the Dual Authorization preferences.
 If the ‘Dual Authorization’ is checked and Threshold Amount/Currency is not maintained
in the Dual Authorization preferences.

2-5
You can invoke “Repairable Fields” screen by clicking on the action button present at the
bottom’.

Verifier validates whether Verifier ID is different from Maker and Checker. Verifier ID,
Verification Status and Verification Date Stamp are captured in this sub screen.

When you click OK, below actions are performed:


 Verification Status is marked as 'Authorized'.
 Verifier ID and Verification Date Stamp gets updated.
 Queue Action Log is updated with Verifier ID, Verification Date stamp and Authorization
Status.
 Transaction is sent for Repair validations.

2.1.1.5 Reject

This sub screen is launched if:


 You have the required Role/User Level access right for the User Action ‘Authorizer’ or
'Verify'.
 Queue authorization status is 'Unauthorized', and Queue Verification Status is
'Unauthorized'.

2-6
You can invoke “Repairable Fields” screen by clicking on the action button present at the
bottom’.

When you click OK, below actions are performed:


 If the Reject action is by Authorizer (Authorization Status is Unauthorized),
– Authorization Status is marked as 'Rejected'. Checker ID, Checker Date stamp is
updated.
– Queue Action Log is updated with Authorization status as 'Rejected'. Checker ID,
Checker Date stamp are updated for the Queue action.
– Queue status is set to 'Pending'.
– Repaired fields values are reset (No repaired information is stored).

Note
 If Dual Authorization is not enabled, Verification status is set as ‘Not Required’.
 If the derived Threshold amount is below the Threshold Amount maintained in the Dual
Authorization preferences, then 'Verification Status’ value becomes ‘Blank’.

 If the Reject action is by Verifier (Verification Status is Unauthorized),


– Verification Status is marked as 'Rejected'. Verifier ID and Verification Date Stamp
will be updated.
– Queue Action Log is updated with Verification Status as 'Rejected'. Verifier ID and
Verification Date Stamp are updated for the Queue action.
– Queue status is set to 'Pending'.
– Repaired fields values are reset (No repaired information is stored).

2-7
2.1.1.6 Other Actions Supported

On selecting a record in the Repair Queue screen and on clicking View Queue Action button,
queue details pertaining to that Transaction reference are displayed.

Actions Functions

Authorize Repair and Cancel operation initiated by a maker can be authorized by


another user.

View Trans- You can view both the inbound and outbound payment transactions that
action are available in Repair Queue in this screen. You can view the
transaction details for the selected record.

Delete Allows deletion of the Repair or Cancel action initiated by a maker, before
authorization.

2.1.2 Business Override Queue

Payment transactions are logged in Business Override Queue if the exception encountered
an overridable business exception as listed below:
 Duplicate Payment
 F23E is HOLD
 F72 Validation failure

2-8
You can invoke the ‘Business Override Queue’ screen by typing ‘PQSOVRQU’ 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 search using one or more of the following parameters:


 Customer Number
 Queue Reference No
 Authorization Status
 Transfer Currency
 Activation Date
 Process Type
 Batch ID
 Source Code
 Transaction Type
 Network Code
 Transfer Amount
 Current Status
 Repair Reason
 Banking Priority
 Source Reference Number
 Transaction Branch
 File Reference Number
 Transaction Reference Number
 Customer Service Model
 Cross Border Transaction Reference Number

2-9
 Error Code
 Maker ID
 Network Type Code

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

The following actions can be performed for transactions in Business Override queue:

Actions Functions

Approve Approve a payment with overrides. The payment is released for fur-
ther processing.

Cancel For the details on, processes followed on cancelling a payment,


refer to section 3.

Authorize Approve/Cancel operation initiated by a user can be authorized by


another user.

Carry For- 1. User can manually move the transaction for processing on next
ward working day. You can move forward the Activation Date manually
through this screen.
2. If a record is released from a queue to proceed with the process-
ing (approve action authorization) with a back date as activation
date, system will move the activation date as current date and initi-
ate the processing from initial validations

Delete Allows the user, who initiated the action to delete the action before
authorization.

View Queue Displays all queue activities performed for the selected transaction.
Actions

View Trans- You can view the selected transaction details.


action

Reject
Reject action opens a new sub screen 'PQDBORJT' to capture remarks during 'Reject' action
by Checker. Reject action is allowed only if Authorization status is Unauthorized and if the
user has access right for 'Authorize' action at Role/User level.

2-10
You can invoke the ‘Reject Details’ screen by clicking the Reject action on the screen.

When you click on OK button in this sub screen, the below processing changes are done:
 Queue Authorization status is updated as 'Rejected'.
 Authorization status in Queue action log is updated as 'Rejected'.
 Queue status gets reset to 'Pending'.
 Reject Remarks if provided by user gets populated against Checker remarks fields of
Queue action log.

User actions Approve / Cancel / Carry Forward are allowed on the Rejected queue record.

2.1.3 Process Exception Queue

In case of runtime errors or missing maintenances on outbound payments as below


transactions are moved to Process Exception Queue:
 Amount not within network limits
 Maintenance missing during processing (Account template, Currency pair etc)
 Customer account is blacklisted for network
 Non-existent customer account

2-11
You can invoke the Process Exception Queues Screen by typing ‘PQSPRQUE’ 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 search using one or more of the following parameters:


 Customer Number
 Transaction Branch
 Queue Reference Number
 File Reference Number
 Network Code
 Transaction Reference Number
 Transfer Currency
 Source Reference Number
 Authorization Status
 Company ID
 Batch ID
 Banking Priority
 Network Type Code

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

The following actions can be performed for transactions in this queue:

Actions Functions

Retry Retry a record. The record is released for further processing.

2-12
Actions Functions

Cancel For the details on, processes followed on cancelling a pay-


ment, refer to section 3.

Authorize Cancel operation initiated by a user can be authorized by


another user.

Delete Allows the user who initiated the action, to delete the action
before authorization.

View Action Allows the user to view the action.


Queue

View Trans- Allows you to view the transaction of the record.


action

2.1.4 Authorization Limit 1 Queue

Highlights of Authorization Limit Queues


 Facility to define two levels of authorization for transaction limits.

When Transfer Amount exceeds the authorization limit 1 amount configured in network
currency preferences, a payment is moved to the Authorization Limit Level 1 Queue.

2-13
You can invoke the Authorization Limit Level 1 Queue Screen by typing ‘PQSAU1QU’ 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 search using one or more of the following parameters:


 Customer Service Model
 Source Code
 Transfer Amount
 Transaction Type
 Queue Reference No
 Maker ID
 Activation Date
 File Reference Number
 Transaction Reference Number
 Payment Type
 Source Reference Number
 Customer Number
 Transfer Currency
 Transaction Branch
 Network Code
 Company ID
 Network Type Code

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

The following actions can be performed for transactions in Authorization Limit Level 1 queue:

Actions Functions

Approve This option enables the further processing of the transaction even if the
amount exceeds authorization limit level 1. On the click of Approve but-
ton, you will be re-directed to a screen to enter necessary remarks. The
transaction is released for further processing after you enter the required
remarks and click the OK button.

Cancel For the details on, processes followed on cancelling a payment, refer to
section 3.

View Queue Displays all queue activities performed for the selected transaction.
Action

View Trans- You can view the selected transaction details.


action

Note
Actions from Authorization Limit 1 queue are authorized automatically.

2.1.5 Authorization Limit 2 Queue

Highlights of Authorization Limit Queues


 Facility to define two levels of authorization for transaction limits.

Note
– Authorization Limits can be configured in Source Network Preferences screen.
– Authorization Limit Level 2 checks is performed after Authorization Limit Level 1
checks.
– Authorization Limit Level 2 checks are not applicable for Batch Booking Payments.
– A payment is moved to the Authorization Limit Level 2 Queue when Transfer
Amount exceeds the authorization limit 2 configured in source network preferences.

2-15
You can invoke the Authorization Limit Level 2 Queue Screen by typing ‘PQSAU2QU’ 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 search using one or more of the following parameters:


 Customer Service Model
 Source Code
 Transfer Amount
 Transaction Type
 Queue Reference Number
 Maker ID
 Activation Date
 File Reference Number
 Transaction Reference Number
 Payment Type
 Source Reference Number
 Customer Number
 Transfer Currency
 Transaction Branch
 Network Code
 Company ID
 Network Type Code

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

The following actions can be performed for transactions in Authorization Limit Level 2 queue:

Actions Functions

Approve This option enables the further processing of the transaction


even if the amount exceeds authorization limit level 2. On the
click of Approve button, you will be re-directed to a screen to
enter necessary remarks. The transaction is released from the
queue for further processing after you enter the required
remarks and click the OK button.

Cancel For the details on, processes followed on cancelling a pay-


ment, refer to section 3.

View Queue Displays all queue activities performed for a transaction.

View Trans- You can view the selected transaction details.


action

Note
Actions from Authorization Limit 2 queue are authorized automatically.

2.1.6 Processing Cutoff Queue

If a payment receipt date time is after the Processing Cutoff time maintained, then the
payment transaction is moved to this queue. This validation is applicable only for current
dated transactions.

You can invoke “Processing Cutoff Queue” screen by typing ‘PQSPRCUQ’ in the field at the
top right corner of the Application tool bar and clicking on the adjoining arrow button. Click
New button on the Application toolbar.

2-17
You can search using one or more of the following parameters:
 Transaction Reference Number
 File Reference Number
 Queue Reference Number
 Network Code
 Payment Transaction Type
 Transaction Branch
 Customer Number
 Transfer Currency
 Transfer Amount
 Cutoff Time
 Value Date
 Customer Service Model
 Source Code
 Source Reference Number
 Company ID
 Batch ID
 Authorization Status
 Network Type Code
 System Action
 Customer Priority

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

The following actions are allowed in the Processing Cutoff Queue:

Actions Functions

Cancel For the details on processes followed on cancelling a payment, refer to


section 3.

Release Although transaction cut off is over, payment can be released for cur-
rent day processing. Payment value date will remain as current date.
Authorization is supported for this action. Payments released from
Processing Cutoff queue does not undergo transaction cut-off time
checks again. You can select multiple records and initiate ’Release’
action.

Carry For- You can manually move the transaction for processing on next work-
ward ing day. Value date will be moved to next working day. Existing value
date will be stored in ‘Original Value Date’ field. Authorization is sup-
ported for this action.

Delete Allows the user who initiated the action, to delete the action before
authorization.

2-18
Authorize Cancel/Release/Carry Forward operation initiated by a user can be
authorized by another user.

View Queue Displays all queue activities performed for a transaction.


Action

View Trans- You can view the selected transaction details.


action

2.1.7 Settlement Review Queue

When the source preference is ‘Default and Verify’, all payment transactions lands in this queue.

If the customer of the payment has a default SSI, the same is picked by default and is moved
here, for verification.

If the customer of the payment doesn’t have a default SSI setup, transaction moves here,
expecting user to manually review and fill.

If the SSI label specified in the transaction is invalid, then the transaction lands on this queue.

You can invoke the Settlement Review Queue by typing ‘PQSSSIQU’ 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 search using one or more of the following parameters:


 Queue Reference Number
 Transaction Reference Number
 SSI Label
 Queue Status
 Transaction Type
 Authorization Status

2-19
 Network Code
 Transaction Branch
 Transfer Currency
 File Reference Number
 Error Code
 Transfer Amount
 Customer Number
 Source Reference Number
 Verification Status
 Network Type Code

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

The following actions can be performed for transactions in this queue:

Actions Functions

SSI label update is allowed for all Payment types. The list of
Repair values will fetch the SSI labels applicable for the customer
network and transfer currency

You can view the settlement details as populated in the trans-


action and approve the same. This does not require authoriza-
Approve tion by another user. The SSI details screen is opened in view
mode on initiating Approve action. Click OK button and com-
plete the action.

Cancel For the details on, processes followed on cancelling a pay-


ment, refer to section 3.

Authorize Cancel/ Approve initiated by a user can be authorized by


another user.

View Queue Displays all queue activities performed for a transaction.


Action

View Trans- You can view the selected transaction details.


action

Delete Allows the user who initiated the action, to delete the action
before authorization.

Verify You can verify the transaction only if dual authorization is ena-
bled.

Reject Either the Authorization status or Verification status is Unau-


thorized, the you can reject the transaction.

2-20
2.1.7.1 Verify

This sub screen is launched if:


 You have the required Role/User Level access right for the User Action 'Verify'.
 Queue authorization status is 'Authorized', and Verification Status is 'Unauthorized'.
 User is different from Maker & Checker.
 If the 'Dual Authorization' check is checked and if the derived Threshold amount is
above the Threshold Amount maintained in the Dual Authorization preferences.
 If the ‘Dual Authorization’ flag is checked and Threshold Amount/Currency is not
maintained in the Dual Authorization preferences.

For Cross Border Outgoing transactions, you can invoke the ‘Settlement Party Details’ by
typing ‘PQDSSIRE’ in the field at the top right corner of the application toolbar and clicking the
adjoining arrow button or by clicking on the action button present at the bottom.

For Cross Border Incoming transactions, you can invoke the ‘Settlement Party Details’ by
typing ‘PQDXISIQ’ in the field at the top right corner of the application toolbar and clicking the
adjoining arrow button or by clicking on the action button present at the bottom.

2-21
For Non-Cross Border payment type Outgoing transactions, you can invoke the ‘Settlement
Party Details’ by typing ‘PQDBSIRE’ in the field at the top right corner of the application
toolbar and clicking the adjoining arrow button or by clicking on the action button present at
the bottom.

When you click OK, below actions are performed:


 Verification Status is marked as 'Authorized'.
 Verifier ID and Verification Date Stamp gets updated.
 Queue Action Log is updated with Verifier ID, Verification Date stamp and Verification
Status.
 Transaction is sent for Settlement validations.

2.1.7.2 Reject

This sub screen is launched if:


 You have the required Role/User Level access right for the User Action ‘Authorizer’ or
'Verify'.
 Queue authorization status is 'Unauthorized', and Queue Verification Status is
'Unauthorized'.

You can invoke “Settlement Party Details” screen by clicking on the action button present at
the bottom depending on the payment type/transaction type as mentioned above in Verify
section.

When you click OK, below actions are performed:


 If the Reject action is by Authorizer (Authorization Status is Unauthorized),
– Authorization Status is marked as 'Rejected'. Checker ID, Checker Date stamp is
updated.
– Queue Action Log is updated with Authorization status as 'Rejected'. Checker ID,
Checker Date stamp are updated for the Queue action.
– Queue status is set to 'Pending'.
– Settlement Party Details provided by user are reset.
 If the Reject action is by Verifier (Verification Status is Unauthorized),
– Verification Status is marked as 'Rejected'. Verifier ID and Verification Date Stamp
will be updated.
– Queue Action Log is updated with Verification Status as 'Rejected'. Verifier ID and
Verification Date Stamp are updated for the Queue action.

2-22
– Queue status is set to 'Pending'.
– Settlement Party Details provided by user are reset.

2.1.7.3 View Queue Action

You can view all the queue activities performed for the selected transaction.

You can invoke “View Queue Action” screen by clicking on the action button present at the
bottom.’.

2.1.8 EU Payer Compliance Queue

Exceptions arising out of the EU Payer Compliance checks, can be handled as part of the EU
Payer Compliance Queue.

Payment moves to EU Payer Compliance Queue, if the Payment does not have the required
information and is suspended based on the STP Action maintained at EU Payer Rule. User
can repair the missing Payment Attributes and authorize it from the Queue so that the
Payment can get into the STP flow again.

2-23
You can invoke ‘EU Payer Compliance Queue’ screen by typing ‘PQSEUPQU’ in the field at
the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can search for the records using one or more of the following parameters:
 Customer Number
 Source Code
 Transaction Branch
 Queue Reference Number
 Transaction Type
 File Reference Number
 Authorization Status
 Network Code
 Transaction Reference Number
 Transfer Currency
 Customer Service Model
 Transfer Amount
 Activation Date
 Source Reference Number
 Company ID
 Banking Priority
 Batch ID
 Suspension Date
 Verification status
 Network Type Code

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

2-24
The EU Payer Compliance Queue is standard Operations Queue, similar to any other
Operations Queue like a Repair Queue or a Business Override Queue.

The Queue Screen itself is a Summary Screen, available with the options of both Search &
Actions. Any payment pending on the EU Payer Compliance Queue will be displayed on the
Dashboards.

In addition, the EU Payer Compliance Queue also shows the aging of the Payment based on
the Deadline days, for receipt of information from the Payer PSP (Payee PSP, in the case of
Collections). When a payment is suspended and moves to the EU Payer Compliance Queue.
Suspension date is derived based on the Suspended Payments retention days maintained at
EU Payer preferences. Beyond which payment is considered as aged.

Following are the actions supported from the EU Payer Compliance Queue:

Repair
You can edit the payment attributes only, for any of the missing/ incomplete information. EU
Payer relevant attributes are Name, Account No. and Address of either Payer or Payee.

On Repair, Rule check is repeated for Missing/incomplete information and if it is Compliance


failure then the respective STP action is applied.

Repair is not allowed if user doesn’t modify any of the missing information.

If repair is done on the transaction for which payment attributes are not mandatory, then it is
treated as an approval and the transaction is processed further.

If any of the field details are changed on Repair, the transaction is marked as ‘Repaired’ and
the sanction XML has the Repaired field as ‘Y’.

Flag 'Override Exception' is used to repair details so that you can mark the approval of the
exception by checking this flag. Override is possible only if the Error type of the error code is
O-override. If the error type is E, on Repair save, system throws an error.

“Override is not allowed for the error code $. Please Repair the field and save again”.

It is mandatory to either modify or approve every row in the repair details.

On authorization of the Repair action, system evaluates the rule again which caused the
original exception, skipping the exceptions which are overridden by the user.

Once all the remaining EU payer rules are validated successfully, the transaction gets moved
to next stage of processing.

Note
Flag 'Override Exception' is applicable to Cross-border, RTGS, SEPA CT, SEPA DD &
SEPA Inst.
Currently, if Repair fields are not populated (i.e. missing information check is not applica-
ble for the rule), then authorization of Repair action will mark the transaction as approved
for further processing. This functionality continues.

2-25
Cancel
This action allows the user to cancel the selected record. On cancel, Payment status is
marked as cancelled.

Authorize
All the actions performed in this queue screen requires authorization. Repair and Cancel
operation initiated by a maker can be authorized by another user.

Verify
This sub screen is launched if:
 You have the required Role/User Level access right for the User Action 'Verify'.
 Queue authorization status is 'Authorized', and Verification Status is 'Unauthorized'.
 User is different from Maker & Checker.
 If the 'Dual Authorization' check is checked and if the derived Threshold amount is
above the Threshold Amount maintained in the Dual Authorization preferences.
 If the ‘Dual Authorization’ flag is checked and Threshold Amount/Currency is not
maintained in the Dual Authorization preferences.

You can invoke “EU Payer Repairable Fields” screen by clicking on the action button present
at the bottom’.

Verifier ID, Verification Status and Verification Date Stamp are captured in this sub screen.

When you click OK, below actions are performed:


 Verification Status is marked as 'Authorized'.
 Verifier ID and Verification Date Stamp gets updated.
 Queue Action Log is updated with Verifier ID, Verification Date stamp and Verification
Status.
 Transaction is sent for EU Payer Repair validations.

Reject
This sub screen is launched if:
 You have the required Role/User Level access right for the User Action ‘Authorizer’ or
'Verify'.

2-26
 Queue authorization status is 'Unauthorized', and Queue Verification Status is
'Unauthorized'.

You can invoke “EU Payer Repairable Fields” screen by clicking on the action button present
at the bottom’.

When you click OK, below actions are performed:


 If the Reject action is by Authorizer (Authorization Status is Unauthorized),
– Authorization Status is marked as 'Rejected'. Checker ID, Checker Date stamp is
updated.
– Queue Action Log is updated with Authorization status as 'Rejected'. Checker ID,
Checker Date stamp are updated for the Queue action.
– Queue status is set to 'Pending'.
– Repaired fields values are reset (No repaired information is stored).

Note
'Verification Status' value is Blank.

 If the Reject action is by Verifier (Verification Status is Unauthorized),


– Verification Status is marked as 'Rejected'. Verifier ID and Verification Date Stamp
are updated.
– Queue Action Log is updated with Verification Status as 'Rejected'. Verifier ID and
Verification Date Stamp are updated for the Queue action.
– Queue status is set to 'Pending'.
– Repaired fields values are reset (No repaired fields information is retained).

View Queue Action


You can view all the queue activities performed for the selected transaction.

2-27
You can invoke “View Queue Action” screen by clicking on the action button present at the
bottom’.

Delete
Allows deletion of the Repair or Cancel action initiated by a maker, before authorization.

View Transaction
You can view the details of the payment transaction selected.

2.1.9 Sanctions Queue

You can invoke “Sanction Queue” screen by typing ‘PQSSNCKQ’ in the field at the top right
corner of the Application tool bar and clicking on the adjoining arrow button. Click New button
on the Application toolbar.

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

2-28
 Transaction Reference Number
 Queue Reference Number
 File Reference Number
 Network Code
 Payment Transaction Type
 Transaction Branch
 Transfer Currency
 Transfer Amount
 Customer Number
 Current Status
 Response Status
 Requested Date
 Response Date
 Sanction System Code
 Authorization Status
 Maker ID
 Cross Border Contract Reference Number
 Source Code
 Customer Service Model
 Source Reference Number
 Primary External Status
 Swift Message Type
 Sanction System Reference Number
 Process Type
 Banking Priority
 Batch ID
 Ring Fenced
 Customer Priority
 Network Type Code
 System Action

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

Payment transaction can have the following sanction check status based on the response
from Sanction check system:
 P-Pending
 A-Approved
 R-Rejected
 O-Interim (Any of the interim status from the external system will be treated as an
override)
 T-Timed Out
 Z-Seized

All payment transactions with the status ‘R’,’O’,’T’ are listed in Sanction check queue. If the
response is received as rejected-’R’, then system cancels the transaction automatically if the

2-29
external system status code is marked for auto cancellation. If auto cancellation is not opted,
transaction is retained in this queue, with response status as Rejected, enabling user to
manually cancel the payment.

Note

If an outbound payment transaction stays in Sanction Queue overnight, as part of the


EOD job, a ring fence block is executed, to hold the funds till Sanction response is
received. An ECA amount block request is triggered to DDA system, while the payment
still remains in Sanction Q. Force block flag is set on, on this request. When Sanction
system responds, following action is taken, based on response:
 Approve or Reject: The Ring fence block is released and transaction is processed
further.
 Seize & Seizure accounting: The Ring fence block is released and transaction is marked
as Seized, after posting seizure accounting.
 Interim Response: Ring fence is not released & waits for final response.

The following actions will be allowed for the Sanction Check Queue:

Actions Functions

Approve User can approve the payments. Authorization is supported for this
action.

Resend This option will allow the submission of transaction for reprocessing.
You can select multiple records and initiate ‘Resend’ action.Resend
Action will not support authorization.
Resend is allowed only when SC status is Timed Out.

Cancel For the details on, processes followed on cancelling a payment, refer
to section 3.

Carry For- Carry Forward action is supported, if a payment is approved by


ward Sanction system, on a later day and the customer’s rollover prefer-
ence is Retain in Queue.
You can manually move the transaction for processing on next work-
ing day.
If a record is released from a queue to proceed with the processing
(approve action authorization) with a back date as activation date,
system will move the Activation Date as current date and initiate the
processing from initial validations.

Authorize Cancel/ Approve initiated by a user can be authorized by another


user.

View Queue Displays all queue activities performed for a transaction.


Action

View Trans- You can view the selected transaction details.


action

Delete Allows the user who initiated the action, to delete the action before
authorization.

2-30
2.1.10 Exchange Rate Queue

You can invoke “Exchange Rate/External Exchange Rate Queue” screen by typing
‘PQSEXEXQ’ in the field at the top right corner of the Application tool bar and clicking on the
adjoining arrow button. Click New button on the Application toolbar.

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


 Transaction Reference Number
 File Reference Number
 Queue Reference Number
 Buy Currency
 Buy Amount
 Sell Currency
 Sell Amount
 External Exchange Rate
 Status
 Module
 Exchange Rate
 Authorization Status
 Network Code
 Host Code
 Payment Type
 Payment Transaction Type
 Transaction Branch

2-31
 Customer Number
 Customer Account Number
 Buy Sell Indicator
 Source Code
 Customer Service Model
 FX Reference Number
 Source Reference Number
 Company ID
 Batch ID
 Account Currency
 Queue Code
 Network Type Code

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

Queue Code
This column indicates, if the transaction is part of the Internal Exchange Rate Queue/ External
Exchange Rate Queue.

The queue code for the transactions landing on this queue is considered as Internal Exchange
Rate Queue if External Exchange Rate Applicable flag is Off at Network Preference. Else, if
this flag is set On, then the queue code is considered as External Exchange Rate Queue.

2-32
The following actions can be performed for transactions in Internal/External Exchange Rate
Queue:

Actions Functions

Cancel For the details on, processes followed on cancelling a pay-


ment, refer to section 3.
1. You can input Exchange Rate manually on this screen & pro-
Edit FX
ceed, if transaction is in Internal Exchange Rate Queue.
Details
2. Exchange Rate, FX reference number & Send Request are
allowed only for transactions in External Exchange Rate Queue,
subject to:
 Outbound transactions with Queue status
Rejected
 Inbound transactions with Queue status Retain in
Queue
3. If Send Request is Yes, an additional request will be sent to
the External Exchange Rate System. If No, the Exchange Rate
input on this screen will be considered as final, and transaction
will be proceeded further.
Resend 1. This action is allowed only for transactions with Queue
Code as External Exchange Rate Queue, and Queue sta-
tus is Timed Out or Pending.
2. This action re-sends a duplicate request to External
Exchange Rate System.
3. No edit of FX details are allowed for queue statuses –
‘Pending/Time out’.
4. You can select multiple records and initiate ‘Resend’
action.
5. Resend Action will not support authorization.

Carry For- 1. User can manually move the transaction for processing on
ward next working day. You can move forward the Activation Date
manually through this screen.
2. If a record is released from a queue to proceed with the pro-
cessing (approve action authorization) with a back date as
activation date, system will move the activation date as cur-
rent date and initiate the processing from initial validations.
3. This action is applicable only for Internal Exchange Rate.

Authorizer Cancel/ Rate Input actions initiated by a user can be author-


ized by another user.

Delete Allows the user who initiated the action, to delete the action
before authorization.

View Queue Displays all queue activities performed for a transaction.


Action

View Trans- You can view the selected transaction details.


action

2-33
2.1.11 FX Unwind Queue

On cancellation or rollover of a transaction which has completed external FX processing, a


reversal request is handed off to FX system automatically.On queue cancellation or rollover
of a cross-currency transaction with External FX reference, the transaction is moved to a FX
Unwind Queue before processing the action.

You can invoke “FX Unwind Queue” screen by typing ‘PQSFXCAN’ in the field at the top right
corner of the Application tool bar and clicking on the adjoining arrow button. Click New button
on the Application toolbar.

Following scenarios are covered with FX Unwind Queue:


 Auto/Manual Rollover
 Cancellation from any queue.

Following are the status updates and process that happens in the FX Unwind Queue:
 The cancel/rollover processing continues in parallel irrespective of the fact that the
transaction is logged in FX unwind queue.
 In rollover cases the transaction is moved to FV queue and on the value date the
processing are done when the job is run for the current value dated transactions, even
if the transaction is pending in the FX unwind queue.
 Releasing the transaction before value date from FX unwind queue, to be operationally
handled.

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


 Transaction Reference Number
 File Reference Number
 Queue Reference Number
 Buy Sell Indicator
 Buy Currency
 Buy Amount
 Sell Currency

2-34
 Sell Amount
 Exchange Rate
 Remarks
 Authorization Status
 Network Code
 Payment Transaction Type
 Transaction Branch
 Customer Number
 Account Number
 Account Currency
 Source Code
 Customer Service Model
 FX Reference Number
 Source Reference Number
 Company ID
 Batch ID
 Instruction Date
 Network Type Code

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

The following actions can be performed for transactions in FX Unwind Queue:

Actions Functions

Approve 1. Upon sending necessary requests for external systems manually


for FX reversal, the user can invoke ‘Release’ action so that the
transaction can be processed further.

2. Cancellation or rollover processing can be continued.However, no


reversal FX request generation is applicable.

3. Authorization is supported for this action.

4. You can provide edit FX reference and FX rate while initiating


Approve action for a transaction pending for rollover.

Authorize Approve action requires authorization.

Delete Allows the user who initiated the action, to delete the action before
authorization for the Approve action.

View Queue Displays all queue activities performed for a transaction.


Action

View Trans- You can view the selected transaction details.


action

2-35
2.1.12 External Pricing Queue

Transaction are moved to External Pricing Exception Queue on the below scenarios:
 Response Timeout
 Unable to handle the response

You can invoke the External Pricing Queue Screen by typing ‘PQSEXPRQ’ 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 search using one or more of the following parameters:


 Customer Number
 Source Code
 Queue Reference Number
 Transaction Reference Number
 Transaction Branch
 Network Code
 File Reference Number
 Transaction Type
 Authorization Status
 Remarks
 Transfer Currency

2-36
 Customer Service Model
 Transfer Amount
 Requested Date
 Response Date
 Source Reference Number
 Company ID
 Batch ID
 Network Type Code

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

The following actions can be performed for transactions in this queue:

Actions Functions

Cancel For the details on, processes followed on cancelling a pay-


ment, refer to section 2.23.

Resend 1.This option allows you to resend a transaction present in the


queue.
2.You can select multiple record and initiate ‘Resend’ action.

Delete Allows the user who initiated the action, to delete the action
before authorization.

View Queue Displays all queue activities performed for a transaction.


Action

View Trans- You can view the selected transaction details.


action

Authorize Cancel/ Approve initiated by a user can be authorized by


another user.

2.1.13 External Account Check Queue

The External Account Check (EAC) request sent from Payment system for credit entries of an
account. This request includes information about account number, account currency, CIF ID
and branch code. The external DDA system has to perform the below validations:
 Existence of the account
 Currency of the account specified is correct
 Account belongs to the customer specified and the customer status
 Account exists on the specified branch
 Account is authorized, active & open
 Account status
 Credit is not restricted on the account

2-37
You can invoke “EAC Queue” screen by typing ‘PQSEACQU’ in the field at the top right corner
of the Application tool bar and clicking on the adjoining arrow button. Click New button on the
Application toolbar.

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


 Transaction Reference Number
 File Reference Number
 Queue Reference Number
 Network Code
 Payment Transaction Type
 Transaction Branch
 EAC Currency
 EAC Amount
 Customer Number
 Current Status
 Response Status
 Requested Date
 Response Date
 EAC System Code
 Authorization Status
 Cross Border Contract Reference Number
 Source Code
 Activation Date
 Customer Service Model
 Maker Id
 Checker Id
 Error Code
 Source Reference Number
 Company ID
 Batch ID
 Process Type
 Secondary External Status
 Network Type Code
 Creditor Account Number

2-38
 System Action
 Customer Priority
 Accounting Included

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

The following actions can be performed for transactions in this queue:

Actions Functions

Approve You can approve the payment. Transaction gets reprocessed.

Resend 1. This option allows the submission of transaction for EAC


again if the request is in Timed Out- 'T' status.
2. You can select multiple records and initiate, ‘Resend’
action.
3. Resend Action does not support authorizations.

Cancel For the details on, processes followed on cancelling a pay-


ment, refer to section 3.

You can initiate Retry action if:


Retry
• The current ECA status of the ECA record is 'Rejected' and
transaction cancellation is not done
• Activation Date is current date, not a back date
The Retry action does not require authorization. Retry of a record
in ECA/EAC queue generates a new Queue Reference.
Carry For- 1. You can manually move the transaction for processing on
ward next working day. You can move forward the Activation Date
manually through this screen.
2. If a record is released from a queue to proceed with the pro-
cessing (approve action authorization) with a back date as
activation date, system will move the activation date as cur-
rent date and initiate the processing from initial validations.

Authorize Cancel/ Approve initiated by a user can be authorized by


another user.

Delete Allows the user who initiated the action, to delete the action
before authorization.

View Queue Displays all queue activities performed for a transaction.


Action

View Trans- You can view the selected transaction details.


action

Delete This action is applicable to batch transactions. You can de-link


a few transactions from a batch and submit the batch for EAC
again.

2-39
You can initiate Retry action if:
Retry
• The current ECA status of the ECA record is 'Rejected' and
transaction cancellation is not done
• Activation Date is current date, not a back date
The Retry action does not require authorization. Retry of a record
in ECA/EAC queue generates a new Queue Reference.

2.1.14 External Credit Approval Queue

Payment transactions which fail/pending Credit approval check for debit entries with DDA
system are moved to ECA queue.

ECA information sent from Payments system includes account number, account currency,
CIF ID, branch code, transaction amount and value date of the transaction. The DDA system
has to perform the below validations based on the received information based on the following
parameters the received information:
 Existence of the account
 Currency of the account specified is correct
 Account belongs to the customer specified and customer status
 Account exists on the specified branch
 Account is authorized, active & open
 Account status
 No Debit is not enabled in the account
 Clear available balance in the account is greater than the transaction amount specified
 Expiry date of the transaction is transaction value date.
 The DDA system puts an amount block so that the specified transaction can be
executed on the transaction value date.

Note
Refer to Payments Core section 3.5.4 for External Credit Approval processing details.

You can invoke “External Credit Approval Queue” screen by typing ‘PQSECAQU’ in the field
at the top right corner of the Application tool bar and clicking on the adjoining arrow button.
Click New button on the Application toolbar.

2-40
You can search using one or more of the following parameters:
 Transaction Reference Number
 File Reference Number
 Queue Reference Number
 Network Code
 Payment Transaction Type
 Transaction Branch
 ECA Currency
 ECA Amount
 Customer Number
 Current Status
 Response Status
 Requested Date
 Response Date
 ECA System Code
 Authorization Status
 Cross Border Contract Reference Number
 Source Code
 Activation Date
 Customer Service Model
 Source Reference Number
 Ring Fenced ECA
 Company ID
 Batch ID
 Banking Priority
 Secondary External Status
 Network Type Code
 Debtor Account Number
 Referral
 System Action
 Customer Priority
 Account Enabled

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

Single payment and as well as batch entries are logged into this queue.

The following actions are allowed in addition to view exceptions:

Actions Functions

Approve You can approve the payment. Transaction will be reprocessed.

2-41
Resend 1. This option allows the submission of transaction for ECA
again if the transaction is 'Timed Out' status. New reference
number will be created.
2. You can select multiple records and initiate ‘Resend’ action 3.
Resend Action does not support authorization.
For the details on, processes followed on cancelling a payment,
Cancel
refer to section 3.
Manual cancel from ECA queue is allowed only when ECA
request is in Rejected or Retain in Queue Status.
You can initiate Retry action if:
Retry
• The current ECA status of the ECA record is 'Rejected' and
transaction cancellation is not done
• Activation Date is current date, not a back date
The Retry action does not require authorization. Retry of a record
generates a new Queue Reference.
Carry For- 1. User can manually move the transaction for processing on
ward next working day. You can move forward the Activation Date
manually through this screen.
2. If a record is released from a queue to proceed with the pro-
cessing (approve action authorization) with a back date as acti-
vation date, system will move the activation date as current date
and initiate the processing from initial validations.

Authorize Cancel/ Approve initiated by a user can be authorized by


another user.

View Queue You can view the View Queue Action of the selected transaction
Action details.

View Trans- You can view the selected transaction details.


action

Delete Allows the user who initiated the action, to delete the action
before authorization.

Note
 The Remarks received from DDA system on the ECA response is displayed under
Remarks column in View Queue Action log, against ECA response.
 When an ECA request is cancelled from ECA Queue. ECA reversal request is sent to
DDA system.
 On the above case, the Remarks received in the ECA response is sent on the ECA
reversal request in the <REMARKS> tag.

2-42
2.1.15 Network Cutoff Queue

You can invoke “Network Cutoff Queue” screen by typing ‘PQSNETCQ’ in the field at the top
right corner of the Application tool bar and clicking on the adjoining arrow button. Click New
button on the Application toolbar.

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


 Transaction Reference Number
 File Reference Number
 Queue Reference Number
 Network Code
 Payment Transaction Type
 Transaction Branch
 Customer Number
 Transfer Currency
 Transfer Amount
 Network Cutoff Time
 Activation Date
 Authorization Status
 Company ID
 Network Type Code
 System Action
 Customer Priority

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

2-43
Payments processed after network cutoff time will be resolved as Network Post cutoff
Payment Transactions. Single payment and batch entries are logged into this queue.

The following actions can be performed for transactions in Network Cutoff queue:

Actions Functions

For the details on, processes followed on cancelling a


Cancel
payment, refer to section 3.

Force 1. Although transaction cut off is over, payment can be


Release released for current day processing.
2.Payment value date will remain as current date. Payments
released from Network Cutoff queue will not undergo network
cut-off time checks again.
3.Authorization is not required for this action. You can select
multiple records from the queue and perform this action.
4.Payments of different payment types can be selected
together.

Carry For- 1.User can manually move the transaction for processing on
ward next working day. Value date will be moved to next working
day. Existing value date will be stored in ‘Original Value Date’
field.
2. If a record is released from a queue to proceed with the pro-
cessing (approve action authorization) with a back date as
activation date, system will move the activation date as cur-
rent date and initiate the processing from initial validations.

Delete Allows the user who initiated the action, to delete the action
before authorization.

Authorize Cancel/Force Release/Carry Forward operation initiated by a


user can be authorized by another user.

View Queue Displays all queue activities performed for a transaction.


Action

View Trans- You can view the selected transaction details.


action

Note
 When transaction is cancelled from NC Queue, ECA reversal request is sent to DDA
system, if ECA amount block was already performed
 On cancellation, the remarks specified in the NC Queue is passed in the <REMARKS>
tag in the ECA reversal request

2-44
2.1.16 Inbound Messages STP Queue

Inbound MT103 / MT 202 / Cov messages awaiting match is listed in this queue screen.

You can invoke the ‘Inbound Messages STP Queue’ screen by typing ‘PQSSTPQU’ 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 search using one or more of the following parameters:


 Message Reference 20
 Transaction Reference Number
 Queue Reference Number
 Message Type
 Authorization Status
 UETR
 Transaction Branch
 Sender BIC
 Current Status
 Network Type Code
 Debit Account
 Transfer Currency
 Transfer Amount
 Value Date
 Network Code

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

2-45
The following actions can be performed for transactions in this queue:

Actions Functions

Release 1. This action is applicable for both Non-STP and waiting for cover
messages.
2. System skips the cover matching and release the message for
further processing.
3. This action requires authorization and queue access / limit
rights.

Cancel 1. Once the user invokes this action, the system captures the can-
cellation remark and cancellation reason code.

2. The system generates Universal confirmation (or) gCCT confir-


mation for MT103 messages as applicable.

Manual This action is applicable for only cover pending messages. Man-
Match ual Match requires authorization and queue access / limit rights.

Authorize Authorization is applicable for the Unauthorized Release, Sup-


press and Manual Match actions.

Delete Allows the user to delete the actions – Release, Suppress and
Manual Match that are unauthorized.

View Trans- You can view the selected transaction details.


action

View Action You can view the View Queue Action of the selected transaction
Queue
details.

Reject
Reject action opens a new sub screen 'PQDMCRJT' to capture remarks during 'Reject' action
by Checker. Reject action is allowed only, if Authorization status is Unauthorized and if the
user has access right for 'Authorize' action at Role/User level.

You can invoke the ‘Reject Details’ screen by clicking the Reject action on the screen.

2-46
When you click on OK button in this sub screen, the below processing changes are done:
 Queue Authorization status is updated as 'Rejected'.
 Authorization status in Queue action log is updated as 'Rejected'.
 Queue status gets reset to 'Pending'.
 Reject Remarks if provided by user gets populated against Checker remarks fields of
Queue action log.
 If the last Queue action is 'Manual Match', then the cover match reference gets reset.
Similarly, if the last Queue action is 'Cancel', then the Reject reason code gets reset.

User actions Manual Match, Release, Cancel are allowed on the Rejected queue record.

2.1.16.1 Manual Match

You can invoke this screen, by clicking on ‘Manual Match’ action button in the ‘Inbound
Messages STP Queue’ (PQSSTPQU).

This action is applicable for only cover pending messages. Manual Match requires
authorization and queue access / limit rights.

User has to select the cover message MT 202COV / MT 910 which is pending for match.
While processing manual match system, tries to match the currency of the payment and cover
message only.

Note
 Any difference in amount due to intermediary charges etc. has to be manually handled.
 Both payment message and cover message will be marked as manually matched.
Payment value date will be derived based on the preference maintained in
PMDCMPRF.

2-47
2.1.16.2 Auto Cover Match Processing

Auto cover matching of the messages MT 103 and MT 202 are supported.

Based on the rule condition mentioned in the Cover Queue Rule maintenance (PMDQURLE),
an incoming payment message (MT103/MT 202) is routed to a STP queue. All payment
messages in this queue await Cover matching. Incoming Cover messages are also routed to
this queue based on the Cover queue rule condition.
 Sanction scanning of MT 202 COV and MT 910 inbound messages are done upfront.
 On successful completion of sanctions screening, the messages are matched with MT
103/ MT 202 messages pending in STP queue for cover match.
 Auto matching considers the following fields value matching between the original
payment message & cover message:
– Reference Number
– Field 20 of payment message with Field 21 of cover message
– Currency & Amount match
 If the auto cover match is successful both payment message and cover message are
marked as ‘Matched’, and payment message is released from STP queue for further
processing.
 Further the payment is sent for Network resolution and will be forwarded to the resultant
payment processor.

2.1.17 Incoming Swift Payment View

You can invoke the ‘Incoming Swift Payment View’ screen by typing ‘PSDIVIEW’ 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.

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.

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

Transfer Type
Select the transfer type of the transaction. Options available are as follows:
 Customer Transfer
 Bank Transfer
 Cover Transfer
 Bank Transfer Own A/c

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.

Consolidation Reference Number


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

Multi Credit Reference Number


Specify the Multi Credit Reference Number of an open multi-credit transfer consol of
customer/bank transfers in which this transaction should included.

gpi Agent
This field is not editable and is disabled. This field has the drop-down values as - Yes/ No.

UETR
UETR is Unique End to End Transaction Reference number. This is a reference number
specific to the transaction which is used to track the transaction through the life cycle.

2-49
PSD Country Option
Specify the PSD Country Option.

PSD Currency Option


Specify the PSD Currency Option.

Generate gpi confirmations


Check this box to for generate the gpi/Universal confirmations.

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


 The required number of days are present between activation date and instruction date
taking into consideration the settlement days, float days and holidays
 Activation date is not a back date
 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.
 If the payment request is received through web services, system will re-derive the activation date
and will proceed with the payment.
 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.
 The’ Value Date change’ action from Future Valued Queue allows providing a new Activation date
& Instruction date
 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.
 If Transfer Currency is specified as CNH in an outbound transaction, then system will
check whether CNH Conversion is required at host level.
 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.

2-50
 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.

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
Specify the foreign exchange reference.

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

Charge Account Number


Specify the Charge Account Number by selecting an account number from the LOV. Charge/
tax amounts are debited to this Charge Account Number. If Charge Account is not available
charge amounts are debited to the transaction debit account.

Charge Account Branch


The system defaults the Branch of the Charge Account selected.

Charge Account Currency


The system defaults the Account Currency of the Charge 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.

2-51
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 will be populated with valid SSI Labels, applicable for the customer and the Net-
work. If Customer or Network details are not available, the fetch action of the list of values
displays 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.

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.

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

Bank Operation Code


Select the bank operation code from the option list. Options available are as follows:
 CRED – Credit Transfer with No SWIFT Service Level
 CRTS – Credit Transfer for Test Purposes
 SPAY – Credit Transfer for SWIFT Pay Service Level
 SPRI – Credit Transfer for Priority Service Level
 SSTD – Credit Transfer for Standard Service Level

If no value is selected then system defaults this field value to “CRED”.

2-52
Note
This is applicable only for customer transfers.

Banking Priority
Specify the priority of banking. Choose between Normal, Urgent and High.

Charge Whom
Specify the charge bearer for the transaction. The list displays the following values:
 OUR
 BEN
 SHA

50:Ordering Customer
The system displays the name and address of the customer ordering the transaction, based
on the debit account selected.

This is applicable only for ‘Customer Transfer’ type of transaction. The ordering customer
details including name and address are defaulted based on the debit account selected.
However you can modify these details.

Chinese code words are supported for Name and address fields of Ordering Customer. Refer
section 3.1.2.11 for details.

52:Ordering Institution
Specify the details of the financial institution that has ordered for the payment to be initiated.

58: Beneficiary Institution


Specify the financial institution which is the ultimate recipient of the funds being transferred.

This is applicable only to Bank Transfers.

You can capture below mentioned details of the Beneficiary Institution here.
 Specify the account number in the first line starting with “/”
 Specify the BIC code in the second line. You can also select the appropriate BIC code
from the adjoining option list that displays all valid BICs maintained in the system.
 You can also specify the Name and Address of the Beneficiary Institution instead of the
BIC Code, in lines 3 to 5.

59: Ultimate Beneficiary


Specify the details of the Ultimate Beneficiary of the payment. This field is available only for
‘Customer Transfer’ type of transactions.

You can capture below mentioned details of the Beneficiary here.


 In Line 1, specify the customer beneficiary account number to which the transaction
amount should be credited. You can specify the IBAN of the account. Alternatively, you
may search and select the account number using LOV if the beneficiary account is
maintained with the bank, which is the case in Inbound payments. This field is available
only for ‘Customer Transfer’ type of transactions.
 Specify the Name and Address of the Beneficiary in lines 2 to 5. Chinese code words
are supported for Name and address fields. Refer section 3.1.2.11 for details.
 Instead of the Name and Address, you can also specify the BIC code of the Beneficiary
in line 2.

2-53
 IBAN validations is conditional mandatory for Cross Border Outbound Payments
– If first 2 character of the Beneficiary Account number does not match IBAN ISO
country code of the BIC (AWI BIC or the receiver BIC if AWI BIC not available), then
the account number is treated as non IBAN.
– IBAN validation is skipped in this case, even if IBAN is mandatory for the country
code derived from the BIC.

For example,
Beneficiary account is maintained as /2121212121, IBAN validation will not be done even if it
is required for the country derived from the BIC.
 Let the country derived from BIC is ‘DE’ and the Account also starts with ‘DE’. System
verifies whether
– IBAN check is required for country code DE
– Whether there is a record available in IBAN Plus for the BIC with
– IBAN ISO country code as ‘DE’
– If yes, then IBAN format validation is done based on IBAN Structure applicable for
DE.
 Let the country code derived from BIC is GB and the account number provided starts
with ‘CH’
– IBAN check is required for country code GB
– Whether there is a record available in IBAN Plus for the BIC with
– IBAN ISO country code as ‘CH’
– If yes, then IBAN format validation will be done based on IBAN Structure applicable
for CH
 IBAN validation for ultimate beneficiary account is done by the system when BIC is
present in tag 57(AWI) and IBAN check is set as required for AWI BIC’s country. System
fetches the ISO country code from BIC code (5th & 6th char).
 IBAN validation is done based on the data maintained in the existing IBAN Information
Maintenance (ISDESBAN)
 If BIC code is not present in tag 57, system fetches the ISO country code from the
receiver of the payment. If IBAN check is required for the receiver country then system
validates IBAN for ultimate beneficiary account.
 These validations are applied on Customer & Bank Transfer transactions, both on
Origination from the system & for pass through cases.

External System Status

You can get the following fields:


 Sanction Check Status
 Sanction Check Reference
 External Account Check Status
 External Account Check Reference
 External Exchange Rate Status
 External Rate Reference

Transaction Status
Transaction Status
Transaction status is displayed.

2-54
Recall Status
This action launches the 'Recall Messages' sub screen as getting launched in PXDIVIEW.

Pending Queue Details

Queue Code is displayed.

Cancellation Error Details

Error Code and Error Description are displayed.

gpi/Universal Confirmation Status


Confirmation Status
Select the Confirmation Status from the following value:
 Ungenerated
 Generated

Confirmation Type
Select the Confirmation Status from the following value:
 Interim

2.1.17.1 Additional Details Tab

You can capture additional information and view field values set by the system for the transaction.

You can invoke the ‘Additional Details’ sub-screen in Transaction Input by clicking the
“Additional Details” link present at the bottom of the screen.

Specify the following details.

53: Sender Correspondent

The system displays the Party Identifier, BIC code or details like Name and Address of the
sender’s correspondent through which the payment transaction should be routed. This value
is populated after deriving the Payment chain as part of the processing. This BIC would be
present in the Currency Correspondent maintenance for the Transfer currency.

2-55
Note
– If an account is present in 53B of the inbound customer transfer & bank transfer then
system will debit account present in 53B and not from the currency correspondent
maintenance.
– The account must be a vostro account and not a nostro account
– If system doesn’t find a valid vostro account the inbound transaction will go to repair
queue

54a: Receiver Correspondent

The system displays the Party Identifier, BIC code or details like Name and Address of the
branch of the receiver or another financial institution in which the funds are made available to
the receiver. This value is populated after deriving the Payment chain as part of the
processing. This BIC would be present in the Global Correspondent maintenance for the
Transfer currency.

55: Third Reimbursement Institution

The system displays the BIC code or details like Name and Address of the receiver's branch,
when the funds are made available to this branch through a financial institution other than that
indicated in Field 53. This value is populated after deriving the Payment chain as part of the
processing. This BIC would be present in the Global Correspondent maintenance for the
Transfer currency.

13C: Time Indication Details

Specify the standard time indication related to the processing of the payment instruction. You
should input the standard Time indication code (placed between ‘/’) followed by Time, a sign
(+ or -) and the Offset from UTC. Alternatively, you can select the time indication code from
the option list. The list displays all valid time indications maintained in the system, which are
CLSTIME, RNCTIME and SNDTIME.

70: Remittance Information

Specify the Remittance Information details from fields 1 to 4.

72:Sender to Receiver Information

This field specifies additional information for the Receiver or other party specified in the lines
from 1 to 6.

Note
For the Outgoing Cross Border/RTGS transaction input screens, system lists the standard
code words such as /ACC/, /INST/, /INT/ except the SWIFT code word /REC/ in the LOV
field 72: “Sender to Receiver Information 1-6”.

2-56
23E: Instruction Codes
Instruction Code 1 through to Instruction Code 6
Specify a standard Instruction code in each field and then input additional information.
Alternatively you can select the standard Instruction code type from the option list. The list
displays all valid instruction codes maintained in the system.

71G: Receiver charges

If Charge Whom field in the Preferences section of the Main tab has a value of “OUR” then
you can specify the Receiver’s charges in case of ‘Customer Transfer’ if they are required to
be included in the Settlement amount.

71F: Sender Charges


Sender Charge Ccy 1 through to Sender Charge Ccy 6
The system displays the charge currency of Sender’s charges that are deducted from the
Transfer amount by this bank (Sender) or by any of the previous banks in the payment chain.
These charges are applicable in case of Customer Transfers and the Charge Whom field
value selected is SHA or BEN.

Sender charge Amount 1 through to Sender Charge Amount 6


The system displays the amount of Sender’s charges.

In case of an Inbound Customer transfer message, each of the previous banks in the payment
chain would have deducted charges from the Transfer amount and details of the same would
be present in the message. The Charge currency and Charge amount of each of these
charges would be populated in up to 6 sets of these fields in addition to the charges deducted
by this bank

77B: Regulatory Reporting Details

Specify the statutory and/or regulatory information required by the authorities in the country
of receiver or sender. You should specify this information by specifying a regulatory code
(placed between ‘/’) followed by 2 character country code and followed by regulatory details.
This information should be specified in up to 3 lines each containing 35 characters.

77T: Envelope Contents Details

Specify the contents of the Envelope in the lines from 1 to 5.

Note
 System supports generation of Outbound MT 103 Remit message. MT 103 Remit
message would be generated if the below mentioned conditions are satisfied:
– Tag 77T details are present
– ‘Remit Member’ flag must be checked for both sender and receiver BIC
– Tag 70 details are not present
 The system will throw error and the transaction is not saved in the below situations:
– If tag 77T details & tag 70 details both are present
– If tag 77T details are present but ‘Remit Member’ flag is unchecked for sender and/
or receiver.
– If tag 77T details are present and ‘Remit Member’ flag is checked for sender and/or
receiver BIC but tag 70 details is also present

2-57
You can view Outbound MT 103 Remit message details on the Outbound Message Browser
screen and on the Messages sub-screen of the Cross Border Outbound Payment Transaction
view screen.

26 T:Transaction Type

You can specify the applicable transaction type code for the transaction.

2.1.17.2 Sequence B - Cover Details

You can invoke this screen by clicking Sequence B - Cover Details tab in the PSDIVIEW
screen.

Inbound messages uploaded will be shown in this screen. Sequence B for Cover details
received in the Inbound message will be displayed in this sub screen.

2.1.17.3 gpi Confirmations

gCCT confirmation messages generated for an Inbound gCCT payment can be viewed from
Inbound Cross Border Payments view screen (PSDIVIEW).

2-58
This screen has ‘Tracker Confirmations’, ‘Our Confirmations’ Tabs displaying gCCT/gCOV
confirmations received from the tracker and gCCT/gCOV confirmations sent out by the bank
branch (in case of pass through transactions).

Following are the details listed under ‘Tracker Confirmations’ and ‘Our Confirmations’ tab in
the screen:

gCCT Confirmations:
 Reference Number
 Message Date and Time
 Status Code
 Reason Code

2-59
 Status Originator BIC
 Forwarded To BIC
 Currency
 Amount
 Exchange Rate (Only for Our Confirmations)

gCOV Confirmations
 Reference Number
 Message Date and Time
 Status Code
 Reason Code
 Status Originator BIC
 Forwarded To BIC
 Currency
 Amount

Message Button
Click on ‘Message’ button, to view gCCT/gCOV confirmation message that was received or
generated and sent out.

2.1.17.4 View Queue Action Log

You can view all the queue actions for the respective transaction initiated. You can invoke this
screen by clicking the ‘View Queue Action’ tab in PSDIVIEW screen, where the Transaction
Reference Number is auto populated and Queue movement related details are displayed.

Following details are displayed:


 Transaction Reference Number
 Network Code
 Action
 Remarks
 Queue Code
 Authorization Status
 Maker ID
 Maker Date Stamp
 Checker ID
 Checker Date Stamp
 Queue Status

2-60
 Queue Reference No
 Primary External Status
 Secondary External Status
 External Reference Number
 Cancel Reason Code
 Cancel Reason Description

You can view the request sent and the corresponding response received for each row in
Queue Action Log.

Also you can view the request sent to and the response received from external systems for
the following:
 Sanction system
 External credit approval
 External Account Check
 External FX fetch
 External price fetch
 Accounting system

2.1.17.5 Incoming Swift Payment View Summary

You can invoke the ‘Incoming Swift Payment View Summary’ screen by typing ‘PSSIVIEW’ 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:


 Authorization Status
 Transaction Status
 Transaction Reference Number
 Related Reference Number
 Source Reference Number

2-61
 Multi Credit Reference Number
 Transfer Type
 Booking Date
 Instruction Date
 UETR
 Incoming gpi
 Sanction Check Status
 External Account Check Status
 External Account Rate Status
 Transaction Currency
 Transaction Amount
 Debit Account Number
 Credit Account Number
 Consolidation Reference Number
 Consolidation Status
 Queue Code
 SSI Label
 PSD Country Option
 PSD Currency Option
 PSD Handling Required

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

You can perform following actions:

Generate Confirmation
On clicking of this action, the SWIFT gpi/Universal Confirmation Manual Generation Detailed
(PXDGPIMC) screen is displayed. The gpi/Universal confirmation message gets generated
on authorization. For more information, you can refer Section 4.1.8 on Cross Border
Payments User Manual.

2.1.18 Warehouse Queue

This queue contains all Future valued payments, or basically payments whose Activation date
is not the current date, of all Payment types.

This Warehouse Queue displays both Outgoing and Incoming payments of all Payment types.

Support for Cancellation of payment from the Warehouse queue is provided.

2-62
You can invoke the Warehouse Queue Screen by typing ‘PQSFUVAQ’ 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 search using one or more of the following parameters:


 Network Code
 Transaction Reference Number
 Payment Transaction Type
 Authorization Status
 Activation Date
 Credit Value Date
 Booking Date
 Transfer Currency
 Transfer Amount
 Customer Number
 Debtor Account Number
 Prefunded Payments
 End To End Id
 File Reference Number
 Transaction Branch Queue Reference Number
 Source Reference Number
 Source Code
 Instruction Date
 Creditor Account Number
 Creditor IBAN
 Debtor Account IBAN
 Customer Service Model

2-63
 User Reference Number
 Company ID
 Queue Action
 Verification Status
 Network Type Code

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

The following actions can be performed for transactions in this queue:

Actions Functions

View Trans- You can select a particular transaction in this queue and click
action this action button. The screen display the transaction details in
the View screen of the applicable payment type.

Cancel
For the details on, processes followed on cancelling a pay-
ment, refer to section 3.

Change You can click this action button for the selected payment. The
Value Date system enables you to move the transaction Activation date
(and also the Value date) further ahead in the future or move
back the date through to the current day (if required).

Authorize Click this button to authorize action for selected transactions.


Cancel and Value Date Change actions require authorization
by another user unless the maker has auto-authorization
rights.

View Queue You can select a transaction and click this action button to
Action show the actions taken by system or users and the associated
audit trail.

Delete You can delete the action taken on a particular transaction


before authorization by clicking this button.

Reject
Reject action opens a new sub screen ''PQDFVRJT' to capture remarks during 'Reject' action
by Checker. Reject action is allowed only, if Authorization status is Unauthorized and if the
user has access right for 'Authorize' action at Role/User level.

2-64
You can invoke the ‘Reject Details’ screen by clicking the Reject action on the screen.

When you click on OK button in this sub screen, the below processing changes are done:
 Queue Authorization status is updated as 'Rejected'
 Authorization status in Queue action log is updated as 'Rejected'
 Queue status gets reset to 'Pending'.
 Reject Remarks if provided by user gets populated against Checker remarks fields of
Queue action log.
 If the last Queue action was 'Change Value Date' [CHG_VAL_DT], then the value dates
are reset.

User actions Change Value Date, Cancel are allowed on the Rejected queue record.

2.1.19 Accounting Queue

You can invoke the Accounting Queue Screen by typing ‘PQSACCQU’ 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.

2-65
You can search using one or more of the following parameters:
 Transaction Reference Number
 Queue Reference Number
 Network Code
 Source Code
 Host Code
 Payment Transaction Type
 Transaction Branch
 Customer Number
 Current Status
 Banking Priority
 Transaction Date
 Network Type Code

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

2-66
The following actions can be performed for transactions in this queue:

Actions Functions

Resend 1. This option will allow the submission of transaction for Accounting
again if the transaction is in Rejected status. New reference number
will be created.
2. You can select multiple records and initiate, ‘Resend’ action
3. Resend Action does not support authorizations

View Trans- You can select a particular transaction in this queue and then click
actions this action button to view the transaction.

View Queue You can select a transaction and click this action button to show the
Action actions taken by system or users and the associated audit trail.

2.1.20 Non STP Queue

The Non STP Queue screen lists all the transaction which are not required to be processed
as STP for specific customers based on STP rule and Customer Restriction Preference
maintenance.

To invoke this screen, type ’PQSNSTPQ’ in the field at the top right corner of the Application Tool
bar and click the adjoining arrow button.

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


 Queue Reference Number

 Transaction Reference No
 Transaction Branch
 Authorization Status
 Network Code

2-67
 Source Code
 Customer Number
 File Reference Number
 Related Reference Number
 Source Reference Number
 Book Date
 Instruction Date
 Current Status
 Channel Type
 Transfer Currency
 Transfer Amount
 Transaction Type
 Debtor Account Number
 Customer Service Model
 Rule Name
 Network Type Code
 Verification Status
On click of ‘Search’ button, system displays the records that match the search
criteria specified.
Following actions can be performed in this browser:

2.1.20.1 Release

This action allows you to release the transaction to further processing, depending on the
payment type (Book/SEPA/Cross Border etc.) and the transaction type (outgoing/Incoming).

2.1.20.2 Modify

After clicking Modify button for the selected transaction, respective Transaction Input screen
gets launched in unlock mode.

Modify action opens the transaction input screen based on the last authorized version of the
transaction.

2.1.20.3 Authorize

After clicking Authorize button for the selected transaction, respective transaction input
screen is opened in Authorize mode.

2.1.20.4 Delete

This action allows you to delete last user action. For example, If maker takes a Cancel user
action by mistake, the maker can undo that action using this 'Delete' action button. If maker
has modified a transaction by mistake, the maker can delete the modification using 'delete'
action.

2.1.20.5 Reject

This action allows you to reject the unauthorized user action.

2-68
2.1.20.6 Cancel Action

When you click on Cancel action, screen PQDNSTPC is launched to capture the Remarks.

Below fields are displayed:


Queue Reference number
This field displays Queue Reference of selected Transaction.

Transaction Reference Number


This field displays Transaction Reference of selected Transaction.

Host Code
This field displays Host Code of selected Transaction.
Network Code
This field displays Network Code of selected Transaction.

Payment Type
This field displays Payment Type of selected Transaction.

Transaction Type
This field displays Transaction Type of selected Transaction.

Transfer Currency
This field displays Transfer Currency of selected Transaction.

Transfer Amount
This field displays Transfer Amount of selected Transaction.

Remarks
You can specify the Remarks.

Queue Status
This field displays Queue Status of selected Transaction.

Reject Code
This field displays the Reject Code (Same list of codes captured in PQDCANQU screen).

2-69
Note
Reject code is same as the reject codes on PQDCANQU screen which intern fetches the
Reject code from PMDRJMNT screen.

Reject Reason
This field displays the Reason of the Reject Code selected.

2.1.20.7 View Message


After clicking View Message, it fetches the underlying message from different data stores,
based on its Channel Type selected and displays the View Message sub screen.

2.1.20.8 View Transaction

After clicking View Transaction button, system launches the respective transaction view
screen based on Payment Type and Transaction Type (Outgoing / Incoming). E.g. For Book
Transfer, the function id 'PBDOTNVW' / For Fedwire Outbound 'PBDOTNVW'. etc.

2.1.20.9 Verify

After clicking Verify button for the selected transaction, respective transaction input screen
is launched.

2.1.20.10 View Queue Action

After clicking View Request Action, existing Queue Action screen (PQDVWQAC) gets
launched and it displays all the user actions taken on this message.

2.1.21 Network Resolution Queue

Payment transactions initiated from Single Payment / C2B / SWIFT pass through / MT101
undergoes network resolution based on the network rule maintained. Payments failed to
derive network, lands in network resolution queue.

2-70
You can invoke the Network Resolution Queue by typing ‘PQSNWRQU’ 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 search using one or more of the following parameters:


 Customer Number
 Debit Account
 Requested Execution Date
 Initiation Date
 Source Code
 Transaction Branch
 Prefunded Payments
 Transfer Currency
 Source Reference Number
 Transaction Reference Number
 File Reference Number
 Company ID
 Batch ID
 Current Status
 Channel Type (SWIFT, SPS, C2B, MT101 & MT204)
 Authorization Status

2-71
 Verification Status

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

Note
Network Resolution Queue displays the transactions that cancelled also in the Queue. If
the Queue status is 'Cancelled' and Authorization Status is 'Authorized', then no user ac-
tion is allowed.

The following actions can be performed for transactions in this queue:

Actions Functions

View Mes- You can select a particular network in this queue and then click
sage this action button to view the message.

Select Net- You can select a particular network in this queue and click this
work action button.

Cancel You can specify the Cancel and Reject/Return related details.

Authorize You can select a particular network in this queue and then click
this action button to authorize the network.

View Queue You can select a network and click this action button to show the
Action actions taken by system or users and the associated audit trail.

Verify You can verify the transaction only if dual authorization is ena-
bled.

Reject Either the Authorization status or Verification status is Unauthor-


ized, the you can reject the transaction.

View Cancel You can view Cancel and Sanction Check related details.
Details

2.1.21.1 View Message

View Message button opens the underlying message of the selected transaction, as below:
 If its Channel is SWIFT (MT103 / MT202), this action will fetch the underlying message
from PMTB_MSG_DLY_MSG_IN data store - SWIFT inbound browser. The message
is displayed on a new sub screen as below:

2-72
 If its Channel is SPS: This action check for the Channel Sub Type of the transaction and
display the message as below:
– If booked via ReST or GW or JSON Over JMS (MDB), then View Message will fetch
the underlying message from PMTB_INCOMING_LOG data store, which is the
staging area for ReST & GW requests of SPS. This sub screen appears as below.
– If booked via UI, then error message "View message not supported for transaction
booked via UI" is displayed.
– If booked via Bulk SPS, then error message " View message restricted for bulk
transactions " is displayed.

 If its Channel is MT101 / MT204 / C2B : Error message will pop up indicating, view
message restricted for bulk transactions. These inbound messages could have multiple
transactions. While the network resolution could have failed for one of its transaction,
displaying all transactions in the message will mislead.

2-73
2.1.21.2 Select Network

This sub screen is launched if you have the required Role/User Level access right for the User
Action 'Select Network'.

You can invoke the ‘Select Network’ screen by clicking on the action button present at the
bottom.

The user can launch the ‘Select Network’ screen to resolve the network code.

This screen contains two section:


 View section: In this section data is displayed as received from the message.
 Edit section: In this section user can update the data.

2.1.21.3 Cancel

This sub screen is launched if:


 You have the required Role/User Level access right for the User Action 'Verify'.
 Current Queue status is 'Pending', and Authorization status is 'Authorized'.
 Only one transaction is selected.

2-74
You can invoke “Cancel” screen by clicking on the Cancel action button.

Remarks field is mandatory. If not entered, an error message is displayed.

Reject Code is mandatory if the channel type is SWIFT. The Reject codes displays all the 'gpi
Reject Reason codes' maintained in SWIFT gpi Static Preferences (PXDGPIST)
maintenance.

2.1.21.4 Verify

This sub screen is launched if:


 You have the required Role/User Level access right for the User Action 'Verify'.
 Queue authorization status is 'Authorized', and Verification Status is 'Unauthorized'.
 User is different from Maker & Checker.
 If the 'Dual Authorization' is checked and if the derived Threshold amount is above the
Threshold Amount maintained in the Dual Authorization preferences.
 If the ‘Dual Authorization’ is checked and Threshold Amount/Currency is not maintained
in the Dual Authorization preferences.

2-75
You can invoke “Verify” screen by clicking on the action button present at the bottom.

Verifier validates whether Verifier ID is different from Maker and Checker. Verifier ID,
Verification Status and Verification Date Stamp are captured in this sub screen.

When you click OK, below actions are performed:


 Verification Status is marked as 'Authorized'.
 Verifier ID and Verification Date Stamp gets updated.
 Queue Action Log is updated with Verifier ID, Verification Date stamp and Authorization
Status.
 Transaction is sent for Network Resolution validations.

2.1.21.5 Reject

This sub screen is launched if:


 You have the required Role/User Level access right for the User Action ‘Authorizer’ or
'Verify'.
 Queue authorization status is 'Unauthorized', and Queue Verification Status is
'Unauthorized'.

2-76
You can invoke “Reject” screen by clicking on the action button present at the bottom.

When you click OK, below actions are performed:


 If the Reject action is by Authorizer (Authorization Status is Unauthorized),
– Authorization Status is marked as 'Rejected'. Checker ID, Checker Date stamp is
updated.
– Queue Action Log is updated with Authorization status as 'Rejected'. Checker ID,
Checker Date stamp are updated for the Queue action.
– Queue status is set to 'Pending'.
– Values provided by Maker for network resolution will be reset.
 If the Reject action is by Verifier (Verification Status is Unauthorized),
– Verification Status is marked as 'Rejected'. Verifier ID and Verification Date Stamp
will be updated.
– Queue Action Log is updated with Verification Status as 'Rejected'. Verifier ID and
Verification Date Stamp are updated for the Queue action.
– Queue status is set to 'Pending'.
– Values provided by Maker for network resolution will be reset.

2.1.21.6 View Queue Action

You can view all the queue activities performed for the selected transaction.

2-77
You can invoke “View Queue Action” screen by clicking on the action button present at the
bottom’.

2.1.21.7 View Cancel Details

On clicking of this button, you can view the ‘View Cancel Details’ sub screen to display the
Sanctions Statuses and Sanctions Request/Response Messages.

In this screen, View Sanction Queue Action log displays the sanctions request/response
messages.

2.1.22 R Processing Queue

You can invoke the R Processing Queue by typing ‘PMSRMSQU’ 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 search using one or more of the following parameters:


 File Name

2-78
 File Reference Number
 Message Date
 Original Transaction Reference
 End to End ID
 Message Type
 Reason Code
 Payment Type
 Network Code
 Authorization Status
 Message Status

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

The following actions can be performed for transactions in this queue:

Actions Functions

Match Trans- This action allows the user to manually match an R-message
action which is in unmatched status.You can select one of the exist-
ing transaction (ACH or direct debit transaction) depending on
payment type.

Suppress This action allows the user to suppress an unmatched R-mes-


Action sage. This can be done when the original match is not found.

Generate This action will be applicable for unmatched camt.056 mes-


camt.029 sages received for a payment transaction (SCT). If no original
transaction is found, the receiving bank can send back the
camt.029 message.

Authorize You can select a particular record from the queue and then
click this action button to authorize the record.

Delete You can select a particular record from the queue and then
click this action button to delete the record.

View Queue You can select a record and click this action button to show
Action the actions taken by system or users and the associated audit
trail.

Note
All actions, Match Transaction, Suppress and Generate camt.029 require authorization.

2.1.23 Dispatch File Browser

Dispatch File browser lists all the dispatch records based on the dispatch reference.A single
dispatch reference can have multiple files attached to it.This screen lists the records for both
SCT and SDD.

2-79
You can invoke the ‘Dispatch File Browser’ by typing ‘PMSDSPBR’ 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 search using one or more of the following parameters:


 File Reference Number
 Network Code
 File Type
 File Status
 Dispatch Type
 Queue Action
 Authorization Status
 Dispatch Date
 Network Status
 File Name
 Queue Reference Number
 Dispatch Reference
 Previous ICF File Reference Number

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

This queue screen is applicable for both ACH and DD transactions.

The following actions can be performed for transactions in this queue:

Actions Functions

1.Select a record and click on Process File to process the


file. Process File is allowed only when the File Status is
Process File either – Pending/Posted.
2. System checks the Network cutoff and change the
settlement date accordingly on clicking Process File.

View File You can view the dispatch file generated using this option.

You can select a record and click this action button to show
View Queue
the actions taken by system or users and the associated
Action
audit trail.

View The file level accounting can be viewed from the Accounting
Accounting Entries screen opened on invoking this action.

This action will open Validation File Details screen (PMDVL-


View
DVW) which provides the CVF/DVF file details received for
Validation File
the dispatch file.

2.1.23.1 View Validation File

This action will open Validation File Details screen, which provides the CVF/DVF file details
received for the dispatch file. The File level network rejects are displayed in this screen.

2-81
You can invoke this screen by clicking the ‘View Validation File’ action button in the Dispatch
File Browser screen (PMSDSPBR)

For the selected record, you can view the following details, that are displayed:
 File Name
 File Reference
 File Reject Reason
 File Business Date
 File Status
 File Cycle Number
 Original File Name
 Original File Reference
 Original File Date & Time

Following actions can be performed from this screen:

Actions Functions

View File User can view the entire XML CVF/DVF file received.

2-82
1.This is applicable if the Network status is rejected or partially
accepted.
2.For a partially accepted file only transactions which are rejected
only will be re-generated.
3. A new file reference is generated for the new file which will be
populated as re-generated file reference, for the original file record.
Regenerate 4.The original file record will be marked as re-generated and no fur-
File ther actions is possible on this record.
5.The re-generated file will create a new record and the CVF/DVF
file received against the new file will be linked to this record.
6. System throws an Override message on re-generating the
file.Once the user accepts the override, action is saved.
7. Regeneration action requires, authorization and Queue access
rights.

1.This initiates the Network reject of the transactions which are


rejected. These transactions can be part of a fully rejected or
partially accepted file/bulk.
Reject 2.Existing auto reject of transactions for a partially accepted file will
Transactions be removed. Transaction rejection has to be manually triggered.
3. System throws an Override message on rejecting the transac-
tion.Once the user accepts the override, action is saved.
4. Reject Transactions action requires, authorization and Queue
access rights.

You can select a particular record from the queue and then click this
Authorize
action button to authorize the record.

You can select a particular record from the queue and then click this
Delete
action button to delete the record.
You can select a record and click this action button to show the actions
View Queue taken by system or users and the associated audit trail.
Action

View Bulk You can view the bulks received in the Network Validation File in this
Details screen on clicking, View Bulk Details.

Accounting Entries for a fully Rejected file


 For a file, if the reject transactions/re-generation is for the entire file, DCLG reversal of
the original entries will be passed.
 If the file is re-generated, re-posting of the entries with the new settlement date will be
done.

Note
Existing upfront reversal of DCLG entries on receipt of a Network reject of a full file is not
applicable.

2-83
Accounting Entries for a partially Accepted file
 For a file, if the reject transactions/re-generation is for the partially accepted file, DCLG
reversal of the original entries will be passed for the transactions which are rejected/
regenerated.
 If the file is re-generated, re-posting of the entries with the new settlement date will be
done.

2.1.23.2 View Bulk Details

You can view the bulk level network rejects in this screen. The bulks rejects that are part of
the Network Reject file can be viewed here.

You can invoke this screen by clicking ‘View Bulk Details’ in Validation File Details screen,
which is an action button (View Validation File) in the Dispatch File Browser screen
(PMSDSPBR).

You can vie the following details in this screen:


 Reject File Reference
 Original File Name
 Bulk Status
 Original File Reference
 Message Type
 Reject File Name
 Reject Reason

2-84
You can perform the following action from this screen:

View Rejected Transaction

You can view the network rejects at the individual transaction level here.You can invoke this
screen by clicking ‘View Rejected Transactions’ from the ‘Validation File Bulk Details’ screen.

Further more you can view the rejected transaction and its complete details by clicking ‘View
Transaction’ action button, which launches the actual transaction screen.

2.1.24 Outbound Charge Claim Queue

All the outbound charge claim message sent is logged in Outbound Charge Claim Queue. To
invoke this screen type ’PQSCOCLQ’ in the field at the top right corner of the Application Tool
bar and clicking the adjoining arrow button.

2-85
You can search using one or more of the following parameters
 Queue reference Number
 Out Claim Reference
 Original Transaction Reference
 Claim Currency
 Claim Amount
 Transaction Branch
 Receiver
 Current Status
 Authorization Status
 Network Type Code
 Network Code

On click of ‘Search’ button, system displays the records that match the search criteria
specified.

Following actions can be performed in the Queue screen:

2.1.24.1 Expense Out

You can invoke the Notify Message screen by clicking on ‘Notify Message ‘action button
available at the left bottom in the ‘Notify Message Details ‘screen (PMSNOTFY)

Select the record and invoke this action, to close the outstanding claim by reversing the
Receivable GL outstanding to an expense GL.

The expense GL maintained in Default Claim preferences PXD191PF is used as the debit
GL.As the entries are posted, claim is marked as Liquidated

2-86
2.1.24.2 Manual Match

Select a record and click the ‘Manual Match’ button to launch the Manual Match detailed
screen, The outstanding claim can be matched with any of the inbound Bank transfer
transaction or with inbound MT 910 received.

Enter the settlement amount in Manual Match screen on selecting MT 202/MT 910 for
matching, where the settlement amount should be less than or equal to Min (Claim amount,
matched message amount).
 If the settlement amount is same as the claim amount the claim will be marked as
liquidated. No entries are posted
 If the settlement amount is less than the claim amount, tolerance will be checked. If the
difference is within the tolerance then the accounting for expensing out the difference
will be passed.
 If the difference is above the tolerance the claim will remain as outstanding. No
accounting is posted

Note
Charge Claim Manual Match (PXDCLMMM) screen can be invoked by clicking the action
button ‘Manual Match’. This will open as standalone screen on clicking the action button:
 On selecting a specific record and on clicking ‘Manual Match’ button, all the details
pertaining to Outbound Claim details, Match Transaction details are displayed.

2.1.24.3 Authorize

Following actions requires authorization:


 Expense Out
 Manual Match

2.1.24.4 Delete

Select a claim for the initiated actions like - ‘Expense Out’, ‘Manual Match’ and click on
‘Delete’ button to delete the actions before authorizing the same.

2.1.24.5 View Queue Action

View the queue actions for the selected claim with the maker/checker details.

Note
Queue rights and transaction limit rights will be verified for every action initiated.

2.1.24.6 View Claim

Outbound Claim message details are displayed in this screen ’PXDCLMVW’ Click on ‘View
Claim’ to open this screen. All the payments received against the claim is listed here.

2-87
2.1.25 Inbound Charge Claim Queue

Any repair type validation failure is encountered while processing inbound claims, the claim is
move to Inbound Charge Claim Queue. Refer Exception Queues User Manual for further
details.

To invoke this screen type ’PQSCLMQU’ in the field at the top right corner of the Application Tool
bar and clicking the adjoining arrow button.

2-88
You can search using one or more of the following parameters:
 Queue Reference Number
 Transaction Branch
 Claim Status
 Authorization Status
 Network Type Code
 Reference Number
 Claim Amount
 Customer No
 Claim Receive Date
 Network Code
 Related Reference Number
 Claim Currency
 Sender BIC
 Claim Reference Number

On click of ‘Search’ button, system displays the records that match the search criteria
specified.

Following actions can be performed in the Queue screen:

2.1.25.1 Approve

Select the record to Approve the outstanding claim settlement. On approving, customer
account or Payable GL will be debited and Nostro will be credited.

2.1.25.2 Repair

Select a record and click the ‘Repair’ button to modify the Claim Currency, Claim Amount,
Debit Account & Settlement Date from the repair screen Repairing the existing details
requires authorization.

2-89
Outgoing Payment Details

The Outgoing Payment Details display outgoing transaction (i.e. MT103, MT202) details.

Fields displayed in the outgoing payment details section are read only fields.

Outgoing Payment Details section displays the transaction details only for the transaction
status matched.

Edit Claim Details

Fields Instruction Date, Debit Account, Claim Currency, Claim Amount on the screen are
displayed under section Edit Claim Details.

Related reference
Specify the Related Reference from the list of values. This field shows the Reference
Numbers of original Unmatched transactions.

2.1.25.3 Reject

Select the record to reject the claim. Records selected will be marked as rejected. This
requires authorization.

2.1.25.4 Authorize

Following actions requires authorization:


 Approve
 Repair
 Reject

2.1.25.5 Delete

Select a claim for the initiated actions like - ‘Approve’, ‘Repair’, ‘Reject’ and click on ‘Delete’
button to delete the actions before authorizing the same.

2.1.25.6 View Queue Action

View the queue actions for the selected claim with the maker/checker details.

Note
Queue rights and transaction limit rights will be verified for every action initiated.

2-90
2.1.25.7 View Claim Transaction

Claim message details and the liked transaction details is displayed in this screen
’PXDCHGCM’ Click on View Claim Transaction to open this screen.All the payments made
against the claim is listed here.

2.1.26 Inbound Cancellation Request Browser


Inbound cancellation request messages (Received for both gSRP and non-gSRP) are
available in this browser.

To invoke this screen, type ’PXSICLBR’ in the field at the top right corner of the Application Tool
bar and click the adjoining arrow button.

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

2-91
 Sender
 Process Status
 Transaction Reference
 Document Number
 Authorization Status
 Network Type Code
 Transfer Type
 Message Reference
 Message Type
 UETR
 gSRP flag
 Transaction Type
 Payment Type

On click of ‘Search’ button, system displays the records that match the search
criteria specified.
Following actions can be performed in this browser:

2.1.26.1 Manual Match


You can invoke the Manual Match screen PXDCANMM by a selecting a record and
clicking on ‘Manual Match ‘action button available at the left bottom in this browser.

Manual Match action from PXSICLBR screen is allowed only if the Process status of
the selected record is ‘Unmatched’. Manual Match requires authorization and queue
access / limit rights.

You can specify the following fields in this screen.


Host Code
The system displays the Host Code of the selected branch of the logged in user.

Message Reference 20
System defaults the value of Field 20 received in cancellation request message.

Transaction Reference
You can select a Transaction Reference from the list of Inbound transaction references which
are not matched with the Inbound cancellation requests.

2-92
Cancellation Message Details

Sender BIC
The system displays the Sender BIC of the cancellation request message.

UETR
The system displays the UETR value from 121 tag received in the message.

Message Type
System displays the SWIFT message type received (192/292)

Message Date
The system displays the date on which the inbound cancellation message is received.

Message
The system displays the cancellation message received

Transaction Details
On clicking the Populate button in PXDCANMM screen, system defaults the following fields
under this section from the inbound transaction reference selected in the LOV.
 Sender BIC

 Transfer Currency
 Transfer Amount
 Value Date
 gpi Enabled
 Message
On Authorization of manual match action, a cancellation request is logged against the matched
transaction. You can view the cancellation request in the ‘Exception’ tab of the matched
inbound transaction. In queue action log of the matched inbound transaction, a record is logged
with action as ‘MATCH’.

2.1.26.2 Interim/Reject
You can invoke the Cancellation Response Details screen PQDCANRP by a selecting a
record and clicking on ‘Interim’ or ‘Reject’ action button available at the left bottom in this
browser.

Interim/Reject action from PXSICLBR screen is allowed only if the Process status of the
selected record is ‘Unmatched’ or ‘Matched’. Reject action is not allowed if the Last
Response Action is ‘Rejected’. Interim/Reject action requires authorization and queue
access / limit rights.

2-93
You can specify the following fields in this screen:

Response Reference
System displays an auto generated reference number in this field.

Response Date
System defaults the current branch date in this field.

Branch Code
The system defaults the Branch code of the matched transaction.

Host Code
The system defaults the Host code of the matched transaction.

Network Code
The system defaults the Network code of the matched transaction.

Recall Reference
The system displays the Field 20 of the incoming MT n92/gSRP request message.

Incoming Recall Date


The system displays the Date on which the incoming MT n92/gSRP request message received.

Related Reference
The system displays the transaction reference of the matched inbound transaction.

Response Action
The system displays the action selected from the PXSCIBLR screen (Interim/Reject).

gSRP flag
The system displays ‘Yes’ in this field if the request is a gSRP request. Else system displays
‘No’ in this field.

Answers (76)
You can input response details in the field by selecting the reason codes from the LOV. You
can input 6 lines of 35 characters. Line 1 LOV displays various reason codes and reason
statuses based on the action selected and the gpi Enabled flag of the matched transaction.

2-94
Action gpi Response Statuses/Recon Codes
Enabled
flag
Interim Yes Will display gSRP Response code for Interim status
within ‘/’ followed by gSRP Reason codes for the Interim
status.
E.g. /PDCR/RQDA
Interim No Will display all response/reason codes applicable for
n96 message
Reject Yes Will display gSRP Response code for Reject status
within ‘/’ followed by gSRP Reason codes for the Reject
status.
E.g. /RJCT/LGCL
Reject No Will display all response/reason codes applicable for
n96 message
Narrative (77A)
You can input the narrative details up to 20 lines with 35 characters each.

Narrative (79)
You can input the narrative details up to 35 lines with 35 characters each.

Copy of at least the Mandatory Fields of the Original Message


You can check the Copy of at least the Mandatory Fields of the Original Message check box if
the fields of the original request message needs to be populated.

 On Authorization of the Interim/Reject action, a gSRP response message is generated


if the request is a gSRP request message. Else a non-gSRP response message is
generated.

 On save and authorization of the ‘Reject’ action, system validates whether the response
is processed within the days allowed if the transaction is gpi-transaction. If the response
date is beyond the ‘Recall Response days’ maintained in gpi Host preferences
(PXDGPIPF), system shows an information message ‘Final gSRP response is being
provided to the Tracker after x calendar days from the receipt of gSRP request’.

 In the field Answers (76), line 1 is mandatory for gpi payments. Other lines in Answers
(76), ‘Copy of at least the Mandatory Fields of the Original Message’ checkbox, field
Narrative 77A and field Narrative 79 are not allowed for gpi payments.

 In View queue action log, queue action is logged for the user action taken against the
message reference. Last Response action in PXSICLBR is updated with the user action
taken. If the Process status is ‘Matched’, Recall Response is logged in the Exception
tab of the matched inbound transaction.

2-95
Confirmation Message Reject Details
Reject Reason Code
Specify the Reject Reason Code from the list of values. Lists all the gpi Confirmation Reject
Reason codes from SWIFT gpi Host Preferences (PXDGPIST).

Reason Description
This field displays the Description of the reject reason code selected.

Suppress Reject gpi/Universal Confirmation


The flag value 'Suppress Reject gpi/Universal Confirmation' is checked during the auto
generation of SWIFT gpi/Universal confirmation message generation processing.

If the field is checked, then the Reject confirmation message gets generated and the message
status is updated as Suppressed. The message is available in Outbound Message Browser
(PMSOUTBR). The message do not get handed off.

If the field is Unchecked, then the Reject confirmation message gets generated and handed
off.

2.1.26.3 Authorize
You can perform the Authorize action only if the authorization status is ‘Unauthorized’.
On Authorize action, the authorization status of the record is marked as ‘Authorized’.

2.1.26.4 Delete
You can perform the Delete action only if the authorization status is ‘Unauthorized’. On
Authorize action, the system reverts the Process status of the record to previous status.

2.1.26.5 View Request


You can view the inbound cancellation request message by performing View Request
Action.

2.1.26.6 View Response Action

You can view the response messages sent out by performing View Response Action. The
latest response message sent out is displayed first in the screen.

2.1.26.7 View Queue Action

You can view the action logs for the cancellation message received against the reference.

2.1.26.8 View Transaction

On clicking the View Transaction button, system launches Inbound SWIFT Payment View
(PSDIVIEW) screen if the matched transaction is of type 'Incoming Message'.

2.1.27 Inbound Cancellation Request Queue

Inbound cross border transactions for which cancellation request messages are received are
available in this queue screen.

To invoke this screen, type ’PQSICLRQ’ in the field at the top right corner of the Application
Tool bar and click the adjoining arrow button.

2-96
You can search using one or more of the following parameters:
 Queue Reference Number

 UETR
 Credit Account
 gSRP flag
 Value Date
 Transfer Amount
 Exception Queue
 Transaction Reference Number
 gpi Enabled
 Current Status
 Transaction Type
 Activation Date
 Transfer Currency
 Authorization Status
 Cancellation Request Reference
 Customer Number
 Transaction Status
 Request Date
 Network Code
 Network Type Code
 Message Type

On click of ‘Search’ button, system displays the records that match the search
criteria specified.

2-97
Following actions can be performed in this browser:

2.1.27.1 Interim/Accept/Reject
You can invoke the Cancellation Response Details screen PQDCANRP by a selecting a
record and clicking on ‘Interim/Accept/Reject’ or action button available at the left bottom
in this browser.

Interim/Accept/Reject action requires authorization and queue access / limit rights. Accept
action is not allowed when the transaction status is Cancelled / Seized / Reversed and the
transaction type is incoming.

Field and the validations is same as Cancellation Response Details screen which is launched
from inbound cancellation browser. For more details, refer Section 2.1.26.2, "Interim/Reject".

2.1.27.2 Authorize
You can perform the Authorize action only if the authorization status is ‘Unauthorized’.
On Authorize action, the authorization status of the record is marked as ‘Authorized’.

2.1.27.3 Delete
You can perform the Delete action only if the authorization status is ‘Unauthorized’. On
Authorize action, the system reverts the Process status of the record to previous status.

2.1.27.4 View Request Action


You can view the inbound cancellation request message by performing View Request
Action.

2.1.27.5 View Response Action


You can view the response messages sent out by performing View Response Action.
The latest response message sent out is displayed first in the screen.

2.1.27.6 View Queue Action

You can view the action logs for the cancellation message received against the reference.

2.1.27.7 View Transaction

This action launches the Inbound Cross Border Transaction View Detailed (PXDIVIEW) if the
'Transaction Type' field value is 'Incoming' and Incoming SWIFT Payment View screen
(PSDIVIEW) if the value is 'Incoming Message.

2-98
2.1.28 Inbound Non-gpi n99 Queue

To invoke this screen, type ’PQSING99’ in the field at the top right corner of the Application Tool
bar and click the adjoining arrow button.

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


 Message Reference 20

 UETR
 Transaction Reference (Indicated by Field 21 & Fetch transaction reference number
from PXDOVIEW, PXDIVIEW)
 Transaction Branch
 Queue Reference Number
 Sender BIC
 Message Type (199, 299, 999 only)
 Status (Pending, Confirmed, Rejected, No Action Required)
 Authorization Status (Authorized, Unauthorized)
On click of ‘Search’ button, system displays the records that match the search
criteria specified.

Following actions can be performed in this screen:

2.1.28.1 Status Update

You can input remarks and select appropriate update status 'Pending, Confirmed, Rejected,
No Action Required', as applicable. You can save the status update.

2-99
Following details are displayed:

Queue Reference Number


This field displays the system generated 16-digit status update reference number.

Message Reference
This field displays Field 20 of the incoming 'n99' message.

Last Updated on
This field displays the date of update.

Message Received Date


This field displays the date of receipt of the 'n99' message.

Branch Code
This field displays the Branch Code.

Related Reference Number (21)


This field displays the Field 21 of the incoming 'n99' message.

Host Code
This field displays the Host Code.

Status Update
This field lists the below values for the user to select as appropriate and update:
 Pending
 Confirmed
 Rejected
 No Action Required

Remarks
You can input remarks as applicable.

Message Type
This field displays the MT messages such as 199, 299, 999.

On click of 'OK' the status update gets saved and submitted for authorization.

2-100
2.1.28.2 Authorize

After clicking Authorize, you can authorize an unauthorized queue action.

2.1.28.3 View Message

After clicking View Message, you can view the incoming MT 'n99' non-gpi message.

2.1.28.4 View Transaction

After clicking View Transaction, you can view the underlying transaction details (incoming or
outgoing).

2.1.28.5 View Queue Action

After clicking View Queue Action, it displays all the actions undertaken for the message from
the queue.

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


 Queue Reference Number

 Reference Id
 Queue Code

2.1.28.6 Delete

After clicking Delete, you can delete an unauthorized queue action.

2-101
2.1.29 Incoming Unmatched Queue

The ‘Incoming Unmatched Queue’ screen lists all the below items:
 All incoming MT202/205 messages which are terminating, and credit account resolution
fails.
 All incoming MT202COV/205COV messages received for cover matching but not
matched against Customer Transfer/Bank Transfer.
 All incoming MT910 messages which are not matched against Customer Transfer/Bank
Transfer & Outbound Claim.
 All incoming MT940/MT950 statement entries which are not matched against Customer
Transfer/Bank Transfer & Outbound Claim

To invoke this screen, type ’PQSIUNMQ’ in the field at the top right corner of the Application Tool
bar and click the adjoining arrow button.

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


 Message Reference 20

 Queue Reference Number


 Transaction Branch
 Value Date
 Message Type (MT202, MT205, MT910, MT940, MT950)
 UETR
 Sender BIC
 Transfer Currency
 Transfer Amount
 Authorization Status (Authorized, Unauthorized)
 Message Receipt Date
 Transaction Reference Number
 Debit Account
 Current Status (Unmatched, Matched, Released)
 Channel Type (SWIFT, C2B, SPS)
 Network Type Code
 Network Code

2-102
On click of ‘Search’ button, system displays the records that match the search
criteria specified.

Note
Beneficiary Institution fields are not populated in the search results section when the mes-
sage type is MT910, MT940, MT950.

Following actions can be performed in this screen:

2.1.29.1 View Message

After clicking View Message, existing Message Details screen (PMDVWMSG) gets launched
and details of incoming message is displayed.

This action is allowed only for the MT910, MT202, MT205, MT202COV, MT205COV message
types.

2.1.29.2 View Queue Action

After clicking View Queue Action, existing Queue Action screen (PQDVWQAC) gets launched
and it displays all the user actions taken on this message.

2.1.29.3 View Transaction

After clicking View Transaction, existing Incoming SWIFT Payment View (PSDIVIEW) screen
gets launched. This action is allowed only for MT202/205 message types.

2.1.29.4 Release

After clicking Release, new sub screen will get launched. Below are details of the of fields to
be displayed in this sub screen. This action is allowed only for MT202/205 message types.

2.1.29.5 Authorize

After clicking Authorize, the above-mentioned sub screen gets launched to capture
authorizer's remarks and Authorize the Release action. Only Checker Remarks are made
available for User Input for 'Authorize' user action.

2.1.29.6 Delete

After clicking Delete, the above-mentioned sub screen gets launched. Both Maker Remarks/
Check Remarks fields are available for user input.

2.1.30 Verification Queue

This screen maintains the Verification Rule. This Rule maintenance would be at the Host level
and for a specific Network Code.

2-103
You can invoke the ‘Verification Queue’ screen by typing ‘PQSVERFQ’ 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 search using one or more of the following parameters:


 Transaction Reference Number
 File Reference Number
 Queue Reference Number
 Network Code
 Payment Transaction Type
 Transaction Branch
 Customer Number
 Transfer Currency
 Transfer Amount
 Authorization Status
 Activation Date
 Current Status
 Source Reference Number
 Source Code
 Verification Status
 Network Type Code

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

The following actions can be performed for the selected transactions:

Actions Functions

View Trans- View outgoing transaction view.


action

View Queue To view all the user actions taken on the transaction.
Action

2-104
Actions Functions

View Mes- Pre-view the generated payment messages.


sage

Force Release the transaction from the queue even if network cutoff is
Release crossed.

Release Release the transaction from the queue to process the transaction
further.

Modify Allowing modification of the transaction data. Branch Input screen


gets launched in unlock mode and you can do modification based
on the amendable fields list.

Cancel Cancelling the transaction in Verification Queue.

Authorize Authorization of the queue action.

Verify This action displays the status of the 2nd Authorization. The Out-
bound Cross Border/RTGS Transaction Input (PXDOTONL) is dis-
played with menu 'Verify' in the screen.

Delete Deletion unauthorized user action by Maker.

Reject Rejection of unauthorized user action by Checker.

2.2 External Response Exception Log Summary


External System response failed during processing, due to technical errors is logged in this
screen. Responses from SC, ECA, External Exchange Rate & Accounting queue are logged
on this.

2-105
You can invoke “External Response Exception Log Summary” screen by typing ‘PMSEXPLG’
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:


 External Reference Number
 Queue Code
 Queue Name

2.2.1 Retry Screen

Click the ‘Retry’ button in the External Response Exception Log Summary screen to invoke
this sub screen.

When a response from external system is failed in processing due to any technical reasons,
the transaction is not be processed further, remains in the same queue. And, the response is
displayed on this screen. You can retry, which re-processes the same response received from
the external system. On successful re-processing, transaction proceeds further and the
response is removed from this screen.

2-106
2.2.2 View Response Screen

Click the ‘View Response’ button in the External Response Exception Log Summary screen
to invoke this sub screen.

The external system response which has failed during process, due to technical reasons are
shown here.

2.2.3 Ignore Screen

Click the ‘Ignore’ button in the External Response Exception Log Summary screen to invoke
this sub screen.

Ignore option on this screen is to ignore the response. So the response is removed from this
screen.Thus the payment could be manually acted from the corresponding exception

Note
This is supported for Sanction, ECA & Accounting queues.

2.3 Accounting Resend Summary


Any accounting entries that are failed in posting to accounting handoff queue, to the DDA
system, are logged on this screen.

2-107
You can invoke “Accounting Resend Summary” screen by typing ‘PMSACRES’ 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:


 Transaction Reference Number
 Payment Type
 Transaction Type

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

Note
Resend action in this screen can re send the same entries from the screen. Once success-
fully posted, the transaction is removed from this screen.

2-108
3. Cancellation from Exception Queues
You can invoke “Cancel Action” screen-by clicking on the Cancel button present in every
Exception Queue.

On cancelling a payment transaction from any Exception Queue, if it has not undergone
Sanction scanning yet, the transaction is sanctioned before cancellation. If the Sanction
response is Approve or Reject, transaction is cancelled. Else, if it is Seize, transaction is
seized.

If the transaction stayed in an Exception Queue over days and cancelled on a later day,
Sanctioning will be done considering SC retry days – even if was sanction scanned earlier.

Remarks to be filled in mandatorily in the cancellation screen.

Additionally, the following changes are executed on a payment, on cancellation, based on its
payment direction

3.1 Cancelling Outbound payment


 If the transaction has crossed ECA stage, on cancellation, the amount is released, by
triggering a release block request to DDA system.
 If the payment is a cross currency transfer (transfer currency & debit account currency
are different) and External FX rate was fetched, the FX utilization is undone, by
triggering a FX unwind request.
 If the transaction is cancelled from Sanction Queue on a later day, the Ring Fence block
made on booking day EOD is undone, by triggering a ECA undo request to DDA system.

3.2 Cancelling Inbound payment


 Cross border / SWIFT based RTGS : Option is available to post the credit to Return GL
or to suppress the entries. Reject / Return details are not applicable.
 SEPA ACH: pacs.004 message is sent back to the sender of pacs.008 automatically, to
return the funds of the cancelled payment.Reject / Return details are mandatory.

3-1
 SEPA DD: pacs.004 or pacs.002 message (considering the network settlement date &
time) is sent back to the sender of pacs.008 automatically, to return the funds of the
cancelled payment. Reject / Return details are mandatory.
 India RTGS: pacs.004 is sent back to the sender of pacs.008 automatically, to return
the funds of the cancelled payment. Reject / Return details are mandatory.

You can invoke “Cancel Action” screen by clicking on the Cancel button present at bottom of
the ‘Repair Queue ‘screen ‘PQSREPQU’.

Note
 Suppress and Cancel actions are not allowed for Inbound ACH and Direct Debits. Only
Return action is allowed.
 Return action is not allowed for Cross Border and RTGS transactions.
 Remarks is mandatory to be given.

3-2
4. Exception and Investigation Queues
4.1 Acting from an Exception Queue on a later day
When payment transaction moves to an Exception Queue and an action is taken a later day,
than the booking day, an override “Activation date is in the past, the dates are re-derived. Do
you want to proceed?” would be sought.

On acceptance, activation date of the payment is force reset to current date. And, by this its
instruction date is re derived and entire exception handling process is re-executed from
beginning.

Processing cutoff is not validated when a payment is processed from a queue on a later day.

When an outbound payment is approved from Sanction or ECA Q on a later day, then
Customer Rollover Preference is applied. Refer Payments Core manual on this.

Alternatively you can disagree on this override and in turn cancel the payment, if it need not
be executed on a later day.

4-1
5. Exception Queues - Export Option

An option is provided in the below listed exception queues to export the user selected records
to an excel sheet:
 Auth Limit1 Queue
 Auth Limit2 Queue
 Business Override Queue
 EAC Queue
 ECA Queue
 EU Payer Queue
 Exchange Rate Queue
 External Pricing Queue
 Network Cut-off Queue
 Non STP Queue
 Process Cut-off Queue
 Process Exception Queue
 Repair Queue
 Sanction Check Queue
 Settlement Review Queue
 Verification Queue
 Warehouse Queue


Export action is considered only on selected records and export the queue records to an excel
sheet.

5-1
6. Function ID Glossary

P PQSING99 ...................... 2-99


PMDQURLE ....................2-48 PQSIUNMQ .................. 2-102
PMSACRES ..................2-108 PQSNETCQ .................... 2-43
PMSDSPBR ...........2-80, 2-82 PQSNSTPQ .................... 2-67
PMSEXPLG ...................2-106 PQSNWRQU ................... 2-71
PMSRMSQU ...................2-78 PQSOVRQU 2-9, 2-12, 2-14, 2-16, 2-
PQDBSIRE ......................2-22 19, 2-36, 2-45, 2-61, 2-63, 2-71, 2-78
PQDSSIRE ......................2-21 PQSPRCUQ .................... 2-17
PQDXISIQ .......................2-21 PQSREPQU ........ 2-2, 2-4, 3-2
PQSACCQU ....................2-65 PQSSNCKQ .................... 2-28
PQSAU1QU ...........2-14, 2-16 PQSSSIQU ..................... 2-19
PQSCLMQU ....................2-85 PQSSTPQU .................... 2-45
PQSEACQU ....................2-38 PQSVERFQ .................. 2-104
PQSECAQU ....................2-40 PSDIVIEW ...................... 2-48
PQSEUPQU ....................2-24 PSSIVIEW ...................... 2-61
PQSEXPRQ ....................2-36 PXDCHGCM ................... 2-91
PQSFUVAQ ....................2-63 PXDCLMMM ................... 2-87
PQSFXCAN .....................2-34 PXDCLMVW ................... 2-87

6-1

You might also like