GPP Business Guide Manual Payment Handling
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 11
Global PAYplus
Manual Payment Handling
Business Guide
Product Version: 4.5
Catalog ID: GPP4.5-00-B36-02-201511
Copyright
© 2017-18 Finastra International Limited, or a member of the Finastra group of companies (“Finastra”). All Rights
Reserved. Confidential - Limited Distribution to Authorized Persons Only, pursuant to the terms of the license
agreement by which you were granted a license from Finastra for the applicable software or services and this
documentation. Republication or redistribution, in whole or in part, of the content of this documentation or any
other materials made available by Finastra is prohibited without the prior written consent of Finastra. The
software and documentation are protected as unpublished work and constitute a trade secret of Finastra
International Limited, or a member of the Finastra group of companies, Head Office: 4 Kingdom Street,
Paddington, London W2 6BD, United Kingdom.
Disclaimer
Finastra does not guarantee that any information contained herein is and will remain accurate or that use of the
information will ensure correct and faultless operation of the relevant software, services or equipment. This
document contains information proprietary to Finastra. Finastra does not undertake mathematical research but
only applies mathematical models recognized within the financial industry. Finastra does not guarantee the
intrinsic theoretical validity of the calculation models used.
Finastra, its agents, and employees shall not be held liable to or through any user for any loss or damage
whatsoever resulting from reliance on the information contained herein or related thereto. The information
contained in this document and the general guidance of Finastra staff does not take the place of qualified
compliance personnel or legal counsel within your institution.
FINASTRA CANNOT RENDER LEGAL, ACCOUNTING OR OTHER PROFESSIONAL SERVICES TO YOUR
INSTITUTION. THE INFORMATION CONTAINED HEREIN IS GENERAL IN NATURE AND DOES NOT
CONSTITUTE LEGAL ADVICE OR A LEGAL OPINION. CONSULT YOUR LEGAL COUNSEL FOR LEGAL
ADVICE SPECIFIC TO YOUR SITUATION OR CIRCUMSTANCES OR TO ANSWER ANY LEGAL
QUESTIONS.
This document is not intended as a substitute for formal education in the regulatory requirements of banking,
banking operations, lending, lending operations, or other topics generally applicable to financial institutions. Your
financial institution is solely responsible for configuring and using the software or services in a way that meets
policies, practices, and laws applicable to your institution, including, without limitation: (1) options and selections
made on prompts; (2) entries in the software program; (3) program setup; and (4) documents produced by the
software or services. It is the obligation of the customer to ensure that responsible decisions are taken when
using Finastra products. Information in this document is subject to change without notice and does not represent
a commitment on the part of Finastra.
Feedback
Do you have comments about our guides and online help? Please address any comments and questions to your
local Finastra representative.
Need more information? Read more about our products at http://www.finastra.com or contact your local Finastra
office at http://www.finastra.com/contact.
Global PAYplus | Manual Payment Handling | Business Guide Page 1
Version Control
Version Date Summary of Changes
1.0 Document Created
2.0 November 2015 Updated for rebranding
3.0 Sept 2018 Document rebranded to Finastra template
Global PAYplus | Manual Payment Handling | Business Guide Page 2
Table of Contents
1 INTRODUCTION ............................................................................................................................. 3
2 TEMPLATES ................................................................................................................................... 3
2.1 Processing ............................................................................................................................... 3
2.1.1 Template Types .................................................................................................................... 3
2.1.2 Creating Templates .............................................................................................................. 3
2.1.3 Updating Templates ............................................................................................................. 4
2.1.4 Canceling Templates ............................................................................................................ 4
2.1.5 Managing Templates ............................................................................................................ 4
2.1.6 Creating Payments from a Template ................................................................................... 4
2.2 Business Setup ........................................................................................................................ 4
2.2.1 System Parameters .............................................................................................................. 4
3 MANUAL HANDLING FOR REPAIR ............................................................................................. 5
3.1 Messages Sent to Repair ......................................................................................................... 5
3.2 Messages Submitted from Repair ............................................................................................ 5
4 BACKOUT QUEUE HANDLING .................................................................................................... 5
4.1 Processing ............................................................................................................................... 6
4.1.1 Processing Flow ................................................................................................................... 6
4.1.2 Alert Profile ........................................................................................................................... 6
4.1.3 Queues ................................................................................................................................. 6
4.2 Business Setup ........................................................................................................................ 7
4.2.1 Profiles .................................................................................................................................. 7
APPENDIX A: GLOSSARY ....................................................................................................................... 8
Global PAYplus | Manual Payment Handling | Business Guide Page 3
1 Introduction
This business guide describes the manual payment handling functionality available in Global PAYplus
(GPP).
Even though it is the objective of a Financial Institution to process payments straight through,
situations do arise where manual intervention and payment monitoring are required. For this purpose,
GPP provides the user with a friendly, intuitive and flexible user interface that facilitates all manual
payment handling activities, as is described in this document.
The user accesses messages via the Queue Explorer. For most actions on messages, the user needs
to select the message or a group of messages.
2 Templates
GPP provides the ability to create templates to assist the user in creating payments that are made
repeatedly, with few or no changes. The usage of templates eases and shortens the time it takes to
create a new payment, especially when the payment needs to be created periodically.
Templates can be created and saved, so that they can be used for different types of regular and/or
predefined payments including Standing Orders and Sweeps.
Templates are used to create new messages/payments using previously defined, pre-populated
messages.
2.1 Processing
2.1.1 Template Types
GPP supports these types of templates:
• Fully repetitive: All message attributes are pre-defined (except value date) and cannot be edited.
Once the message is created out of the template it is ready to be used.
• Partially repetitive: Some message attributes are pre-defined and some are defined when the
message is created.
• Standing order: Fully repetitive templates are associated with a Standing Order profile, which
defines when to generate the payments. All the mandatory information must be defined in the
template except for the Value Date, which is determined by the Standing Order profile. For more
information, see GPP Business Guide Standing Order & Sweeps.
2.1.2 Creating Templates
To create a template:
1. From Create Payment, at the top of the workspace, select a template:
- Customer Payment Template: The message type is pacs.008
- Bank Payment Template: The message type is pacs.009
2. Select the relevant template type. For more information, see Template Types.
3. In the template. Specify values for the fields that should have predefined values, for example,
Template name is a mandatory field.
- If the template type is Partially repetitive, additional details can be added when the message
is created. Therefore, fields in the template can be locked so that they cannot be changed
when using the template for a payment.
› To lock a field in a template, right click and select Mark as unchanged. The field color is
changed as defined by system parameter GUIC_UNCHANGED.
Global PAYplus | Manual Payment Handling | Business Guide Page 4
› To unlock a field in a template, right click and select Unmark. The field color changes
back to its original color.
4. Click Submit to save the template or Save Draft to save a draft template.
5. Once the template has been saved, GPP assigns a unique ID (MID) to the template.
6. Once the status of the template is Complete it can be used for a payment.
Note: Templates do not go through a regular payment processing flow and therefore, GPP does not
process related errors when creating the template.
2.1.3 Updating Templates
Changes to the template do not affect previously created payments.
If a template needs to be amended:
1. In the MQ Explorer main page, search for the template using the MID.
2. Send the template to Repair.
3. Amend the template (and verify if the system rule Message workflow determination requires doing
so).
4. Submit the template.
2.1.4 Canceling Templates
If a message is canceled before saving, the template is not created.
To cancel the message:
1. Click Cancel Request.
2. Click Exit.
2.1.5 Managing Templates
The GPP service, ActivateMatureTemplate service automatically deletes all the cancelled templates
from GPP. The templates are deleted after the pre-defined number of days mentioned in the system
parameter ARCKEEPHISTMPLT.
2.1.6 Creating Payments from a Template
To create a payment from a template:
1. From Create Payment, at the top of the workspace, select Create Payment from Template. This
associates the template ID to the payment.
2. Select Search template.
3. Select the required template.
- If the status of the template is not Complete an error is generated.
- If the status is Complete, the Template fields are copied to the payment. The payment is
validated against the snapshot of the template at the time of creation
4. Click on New Payment icon; each payment gets a unique ID (MID) and is associated to a
template ID (Template MID).
2.2 Business Setup
2.2.1 System Parameters
This is a list of systems parameters which are specific for Manual Payment Handling.
Global PAYplus | Manual Payment Handling | Business Guide Page 5
System Parameter Description
GUIC_UNCHANGED Color coding for partial repetitive template GUI fields that are marked as
unchanged. This option is used only at the *** level.
GUIC_UNCHANGED Color coding for partial repetitive template GUI fields that are marked as
unchanged. Example of value is AB34DE
ARCKEEPHISTMPLT Specifies the number of days to keep the cancelled templates in the
active database before being removed. Used in task: Clean Old Historic
Messages
3 Manual Handling for Repair
Even though it is the objective of a Financial Institution to automatically process payments straight
through, when a payment is routed to Repair manual intervention is required.
3.1 Messages Sent to Repair
When a message is received from the channel or external application, GPP attempts to automatically
process the payment to Complete status.
When a payment fails to complete processing, GPP routes the payment to the Repair queue and
enters in the reasons the payment failed in the error log.
From the Repair Queue a user can handle the message, based on the details in the error log at the
bottom of the message page. There is no indication of erroneous fields in the message page.
Examples of the details of STP failures in the error log:
• Error Code 40038: Party cannot be found. Invalid BIC: AABSDD31XXX.
• Error Code 99017: Invalid DD TPACS878121123. Debtor agent BIC does not match the mandate
debtor bank BIC. Mandate ID: ES5PATDDINCUST12 Creditor ID ES99GPPPATCUST15.
• Error Code 40161: Payment future value date (2013-07-29) is greater than the MOP max
extension (2013-06-19).
• Error Code 40036: Party cannot be found. Invalid IBAN: DE76500109000033332063.
• Error Code 40014: MOP ADDB2CST2 is invalid, the reason is: Membership Validation – no valid
membership record found.
3.2 Messages Submitted from Repair
When a payment is manually created or in Repair (due to an STP error), and the user clicks Submit:
Fields with errors, based on the related Message STP Validation profile, are highlighted in red on the
message page (for example, in the Message STP Validation profile the field was marked as
mandatory but in the message page it has no value). Details of these errors are entered in the
message fields validation list at the top of the message page and include a link to the relevant field in
the message page. Click the link, to access the field.
Details of all other payment processing errors are entered in the error log at the bottom of the
message page, as part of the payment processing. The user can handle the errors based on the
details in the error log.
4 Backout Queue Handling
The Backout queue handles technical failures related to MQ, with minimal effect on the existing
infrastructure. The queue handles technical failures, rather than business failures, which are handled
in the Repair queue.
Global PAYplus | Manual Payment Handling | Business Guide Page 6
GPP handles failed incoming messages using Backout queues.
• Backout queues are defined for each incoming queue in the MQ explorer. Each Backout queue is
related to the primary queue, with the relevant number of rollbacks defined and relevant number
of listeners defined per interface.
Naming convention: [original name]_BACKOUT, for example, Q_IN_FEEDER_BACKOUT.
• Alerts can be defined to notify the administrator when failed messages are received by GPP and
are ready to be reviewed.
Messages are routed to the Backout queue if there is:
• An unhandled exception – an error not anticipated by GPP for which there is no code protection.
The message is rolled back to the MQ queue, since MQ is part of the transaction message. If it
fails more times than the Backout threshold, it is moved from the MQ queue to the Backout
queue.
• An error, which may be temporary, occurs. To keep GPP consistent the message is rolled back
with the assumption that the error will not occur when the message is reprocessed. If the error
occurs more times than the Backout threshold, the message is routed to the Backout queue.
4.1 Processing
4.1.1 Processing Flow
The Failed Incoming Interaction profile allows the administrator to review failed messages from the
Backout queues and decide whether to process them again or delete them.
These options are available:
• Resend message: the original message is resent from Backout queue to primary queue, to be
reprocessed. The entry is deleted from the MESSAGE_BACKOUT table in the database. Dual
control can be set for message resend.
If the user clicks Save the Resend checkbox must also be selected. If it is not selected, a
message error is generated.
• Delete message: Message status changes to delete. The housekeeping clean task, deletes the
old deleted entries. Dual control can be set for message delete. If the user clicks Delete the
Resend checkbox must not be selected. If it is selected, a message error is generated.
For incoming messages, if there are errors in the message they cannot be fixed. A new message
must be created in GPP, with corrected parameters, and sent for processing. The user can select the
entire interface content and copy it.
4.1.2 Alert Profile
Alert type Failed Incoming Interaction, in the Alerts profile, is automatically set to On when there are
messages in the MESSAGE_BACKOUT table, where MESSAGE_BACKOUT.REC_STATUS <>
‘DL’.The alert notifies the administrator when messages fail and are ready to be reviewed.
4.1.3 Queues
For each incoming queue there must be a Backout queue defined in MQ explorer.
For each queue the number of rollbacks should be defined (recommended default number: 3).
The number of rollbacks is defined in the specific Queue by setting the Backout threshold definition in
the queue properties. Alternatively the queue can be defined using this command line set up:
runmqsc FUNDTECH.QM << EOF
DEFINE QLOCAL(Q_IN_FEEDER_BACKOUT) DEFPSIST(YES)
ALTER QLOCAL(Q_IN_FEEDER) BOQNAME(Q_IN_FEEDER_BACKOUT) BOTHRESH(3)
Global PAYplus | Manual Payment Handling | Business Guide Page 7
4.2 Business Setup
4.2.1 Profiles
These are the details of the required setup in GPP profiles for manual payment handling.
Note: For a detailed description of all the fields in the Profiles, see GPP Online Help.
4.2.1.1 Failed Incoming Interaction Profile for Backout Queues
A Message Backout profile allows the handling of failed incoming transactions from Backout queues.
For more information, see Processing Flow.
4.2.1.2 Alert Profile for Backout Queues
For more information, see Alert Profile.
4.2.1.3 Alert Type
Alert type Failed Incoming Interaction is set to On if there are active messages in the
MESSAGE_BACKOUT table.
The value is added in the FIELDS_VALUE table where FIELD_TYPE = ALERT_CATEGORY:
• VALUE_CODE = 30
• VALUE_DESCR = Failed incoming interaction
4.2.1.4 Interface Profile
In GPP, to receive incoming messages, the number of listeners must be more than 0.
The number of listeners for a queue is dependent on the physical machine capacity (number of
resources, queues and processes that can be run on the same machine). More listeners per queue
allows more messages to be received in parallel.
Global PAYplus | Manual Payment Handling | Business Guide Page 8
Appendix A: Glossary
Term Description
STP Straight Through Processing
Global PAYplus | Manual Payment Handling | Business Guide Page 9
© Finastra Limited
All rights reserved
Registered in England & Wales
No. 01360027
Registered Office
4 Kingdom Street Paddington
London W2 6BD
