Business Guide GPP Mass Payments DD

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 76

Global PAYplus Version 4.6.3
Mass Payments
Business Guide
Copyright
© 2009-2016 D+H Global Transaction Banking Solutions. All rights reserved. D+H is a trademark of D+H Limited
Partnership.
PROPRIETARY AND CONFIDENTIAL - This document contains information, which contains Confidential and
Know How property of D+H. Disclosure to or use by persons who are not expressly authorized in writing by D+H
is strictly prohibited.
D+H reserves the right to alter the specifications and descriptions in this publication without prior notice. No part
of this publication shall be deemed to be part of any contract or warranty unless specifically incorporated by
reference into such contract or warranty.
All brand or product names are the trademarks or registered trademarks of their respective holders.
The information contained herein is merely descriptive in nature, and does not constitute a binding offer for the
license of the product described herein.
Catalog ID: GPP4.6-00-B23-03-201606
Mass Payments Version Control
Global PAYplus Business Guide Page 3
Version Control
Version
Date
Summary of Changes
1.0
Document Created
2.0
August 2015
New structure and amended contents
3.0
November 2015
Updated for rebranding
Mass Payments Table of Contents
Global PAYplus Business Guide Page 4
Table of Contents
1 INTRODUCTION .......................................................................................................................... 6
1.1 Overview ............................................................................................................................... 6
1.2 Mass Payments File Levels .................................................................................................. 6
1.3 Message Types ..................................................................................................................... 7
1.3.1 Payment Initiation .............................................................................................................. 7
1.3.2 Payment Clearing and Settlement .................................................................................... 7
1.3.3 Exceptions and Investigations ........................................................................................... 8
1.3.4 Bank to Customer Cash Management .............................................................................. 8
1.3.5 Credit Transfer R Messages ............................................................................................. 8
1.3.6 Direct Debit R Messages ................................................................................................... 9
1.3.7 Mixed Files ........................................................................................................................ 9
1.4 GPP Message Types Terminology ....................................................................................... 9
2 PROCESSING ........................................................................................................................... 11
2.1 Credit Transfer Process ...................................................................................................... 11
2.1.1 Incoming File Handling .................................................................................................... 11
2.1.2 Preprocessing Transactions ............................................................................................ 14
2.1.3 Payment Grouping (Sub Batch) Generation ................................................................... 21
2.1.4 Execution ......................................................................................................................... 25
2.1.5 Execute Individual ........................................................................................................... 26
2.1.6 Execute Bulk Destination ................................................................................................ 27
2.1.7 Acknowledgment Reporting ............................................................................................ 29
2.1.8 Mass Payments Accounting ............................................................................................ 30
2.2 Direct Debit Process ........................................................................................................... 31
2.2.1 Incoming File Handling .................................................................................................... 31
2.2.2 Preprocessing Transactions ............................................................................................ 35
2.2.3 Payment Grouping (Sub Batch) Generation ................................................................... 45
2.2.4 Execution ......................................................................................................................... 48
2.2.5 Execute Individual ........................................................................................................... 50
2.2.6 Execute Bulk Destination ................................................................................................ 51
2.2.7 Acknowledgment Reporting ............................................................................................ 53
2.2.8 Compensation Calculation .............................................................................................. 53
2.2.9 Mandate Management, Validation & Enrichment ............................................................ 55
3 MANUAL HANDLING ................................................................................................................ 58
3.1 Manual Repair ..................................................................................................................... 58
3.2 Manual Repair Accounting .................................................................................................. 58
3.3 Manual Cancellation ........................................................................................................... 58
3.3.1 Incoming File Cancellation .............................................................................................. 58
3.3.2 Incoming Batch Cancellation ........................................................................................... 59
3.3.3 Incoming Transaction Cancellation and Reversal ........................................................... 60
3.4 GPP Mass Payments User Interface .................................................................................. 61
3.4.1 File Summary .................................................................................................................. 61
3.4.2 Batch Summary ............................................................................................................... 62
3.4.3 Pending Outgoing Files Summary................................................................................... 63
3.4.4 Pending Outgoing File ..................................................................................................... 63
3.4.5 Transaction Data ............................................................................................................. 63
Mass Payments Table of Contents
Global PAYplus Business Guide Page 5
4 BUSINESS SETUP .................................................................................................................... 64
4.1 Profiles ................................................................................................................................ 64
4.1.1 Accounts Profile............................................................................................................... 64
4.1.2 Batch Control Profile ....................................................................................................... 64
4.1.3 Bulking Profile.................................................................................................................. 64
4.1.4 Direct Debits .................................................................................................................... 65
4.1.5 Override STP Profiles ...................................................................................................... 66
4.1.6 Interest Rates Profile ....................................................................................................... 66
4.1.7 Interest Types Profile ...................................................................................................... 67
4.1.8 Method of Payment Profile .............................................................................................. 67
4.1.9 Parties Profile .................................................................................................................. 67
4.2 Rules ................................................................................................................................... 68
4.2.1 Advising Type Selection Rules ........................................................................................ 68
4.2.2 Batch Validation............................................................................................................... 68
4.2.3 Bulking Sending Time Rules ........................................................................................... 68
4.2.4 File Department Rule ...................................................................................................... 68
4.2.5 File Priority Rules ............................................................................................................ 68
4.2.6 Incoming File Filter Rules ................................................................................................ 69
4.2.7 Parties Bulking Profile Selections Rules ......................................................................... 69
4.2.8 Sub-Batch Filter Rules .................................................................................................... 70
4.2.9 Fee Type Selection Rule/Fee Formula Selection Rule ................................................... 70
4.2.10 Mandate Validation Rules ............................................................................................... 70
APPENDIX A: MASS PAYMENT FILE HEADER ................................................................................ 71
APPENDIX B: STP VALIDATION ERROR STATUSES ..................................................................... 73
APPENDIX C: FLOW LEGEND ........................................................................................................... 74
APPENDIX D: GLOSSARY .................................................................................................................. 75
Mass Payments Introduction
Global PAYplus Business Guide Page 6
1 Introduction
Note: This Business Guide is currently being certified for GPP V4.5; therefore, there may be
amendments in the future. For more information, please contact your D+H Project Manager.
1.1 Overview
Global PAYplus (GPP) Mass Payments enables Financial Institutions (FI) to receive, process, and
send files that contain multiple payment, collection, and related transactions.
The GPP Mass Payments functionality:
Receives files that contain multiple transactions from clients, clearing partners/partner banks and
clearing systems
Distributes transactions into chunks (manageable groups) and handles the chunks simultaneously
using parallel processing
Generates single or consolidated postings
Generates outgoing files
GPP supports the following Mass Payment Instruments:
Credit Transfer: An initiating party (debtor) sends payment instructions to the bank ordering the
transfer of funds from a debtor account to a creditor account. In a mass payment scenario, the FI
receives a file containing multiple credit transactions. The transactions instruct the FI to transfer
funds from a single debtor account to multiple creditor accounts held at clearing participant FIs.
For example, a company pays employee salaries using monthly mass payment credit transfers.
After processing to completion, the company’s account is debited for the total amount of all
transactions and each employee’s bank account is credited for the amount specified in the
relevant individual transaction at the relevant bank.
Direct Debit: An initiating party (creditor) sends collection instructions to the bank requesting the
transfer of funds from a debtor account to a creditor account. In a mass payment scenario, the
initiating party, such as a FI customer or clearing partner, sends a file containing multiple direct
debit transactions. The transactions instruct the FI to collect funds from multiple debtor accounts,
held at clearing participant banks, and credit a single creditor account.
For example, a utility company, bills its customers using a monthly mass payment direct debit.
After processing to completion, the company’s account is credited for the total amount of all
transactions and each customer bank account is debited for the amount specified in the relevant
individual transaction.
To process a direct debit, a valid mandate must exist between a debtor and creditor. Authorized
GPP users can create and manage mandates using Mandate profiles in the GPP GUI. For
information about mandates, see Direct Debit Mandate Management.
Upon receipt of a direct debit, GPP verifies that a valid mandate exists by implementing the Direct
Debit Mandate Validation processing. For information about the service, see Mandate Validation.
R Messages: GPP supports all R messages including Reject, Return, and Recall. For more
information, see Credit Transfer R Messages and Direct Debit R Messages.
1.2 Mass Payments File Levels
GPP supports the following file levels:
Bulk: GPP processes one bulk (one group header) per file and stores it in the File Summary.
Payment Information (Batch): Each bulk can have one or multi payment information (PaymentInf)
Mass Payments Introduction
Global PAYplus Business Guide Page 7
Individual: Each payment information contains one or multi individual transactions.
Bulk, payment information and individual transactions are visible in the GPP User Interface (UI).
1.3 Message Types
GPP Mass Payments supports both credit transfers and direct debits. Both message types, based on
ISO20022 standards, can be exchanged between the following parties:
Initiating Party and Financial Institution (FI): Messages exchanged between an initiating party
(usually a bank customer) and a financial institution (a bank) are usually in Payment Initiation
(pain) format. A pain message can be either a credit transfer (pain.001) or direct debit (pain.008).
Financial Institutions (FI): Messages exchanged between two financial institutions (a bank and
a CSM) are usually in Payment Clearing and Settlement (pacs) format.
1.3.1 Payment Initiation
Message
Type
Description
pain.001
Customer Credit Transfer Initiation
This message is sent by the initiating party to the forwarding agent or
debtor agent. It is used to request movement of funds from the debtor
account to a creditor. It can contain one or more customer credit transfer
instructions.
pain.002
Customer Payment Status Report
This message is sent by an instructed agent to the previous party in the
payment chain. It is used to inform this party about the positive or negative
status of an instruction (either single or file). It is also used to report on a
pending instruction.
pain.007
Customer Payment Reversal
This message is sent by the initiating party to the next party in the payment
chain. It is used to reverse a payment previously executed.
pain.008
Customer Direct Debit Initiation
This message is sent by the initiating party to the forwarding agent or
creditor agent. It is used to request single or bulk collection(s) of funds from
one or various debtor's account(s) for a creditor.
1.3.2 Payment Clearing and Settlement
Message
Type
Description
pacs.002
FI To FI Payment Status Report
This message is sent by an instructed agent to the previous party in the
payment chain. It is used to inform this party about the positive or negative
status of an instruction (either single or file). It is also used to report on a
pending instruction.
pacs.003
FI To FI Customer Direct Debit
This message is sent by the creditor agent to the debtor agent, directly or
through other agents and/or a payment clearing and settlement system. It
is used to collect funds from a debtor account for a creditor.
pacs.004
Payment Return
This message is sent by an agent to the previous agent in the payment
chain to undo a payment previously settled.
Mass Payments Introduction
Global PAYplus Business Guide Page 8
Message
Type
Description
pacs.007
FI To FI Payment Reversal
This message is sent by an agent to the next party in the payment chain. It
is used to reverse a payment previously executed.
pacs.008
FI To FI Customer Credit Transfer
This message is sent by the debtor agent to the creditor agent, directly or
through other agents and/or a payment clearing and settlement system. It
is used to move funds from a debtor account to a creditor.
1.3.3 Exceptions and Investigations
Message
Type
Description
camt.029
Resolution Of Investigation
This message is sent by a case assignee to a case creator/case assigner.
It is used to inform of the resolution of a case, and optionally provides
details about:
the corrective action undertaken by the case assignee
information on the return where applicable
camt.056
FI To FI Payment Cancellation Request
This message is sent by a case creator/case assigner to a case assignee.
It is used to request the cancellation of an original payment instruction. It is
exchanged between the instructing agent and the instructed agent to
request the cancellation of an interbank payment previously sent.
1.3.4 Bank to Customer Cash Management
Message
Type
Description
camt.054
Bank To Customer Debit Credit Notification
This message is sent by the account servicer to an account owner or to a
party authorized by the account owner to receive the message. It can be
used to inform the account owner, or authorized party, of single or multiple
debit and/or credit entries reported to the account.
1.3.5 Credit Transfer R Messages
GPP supports these Credit Transfer R messages.
Initiating Party
Description
Debtor Bank
A debtor bank requests to cancel a previously transmitted
credit transfer.
Creditor Bank
A creditor bank rejects a transaction received from an initiating
party, such as a bank customer. The rejection is sent to CSM
which in turn is sent back to the debtor bank.
Creditor Bank
A creditor bank approves a recall message received from a
debtor bank, which results in the generation of a return
message. In addition, a creditor bank returns a received post-
settlement transaction that cannot be processed to completion.
Mass Payments Introduction
Global PAYplus Business Guide Page 9
Initiating Party
Description
Creditor Bank
A creditor bank rejects a recall message received from a debtor
bank, which results in the generation of a recall rejection
message. A debtor bank receives a recall rejection as a
negative response for a recall message.
1.3.6 Direct Debit R Messages
GPP supports the following categories of R messages:
Pre-Settlement: The R message is sent before the transaction is settled in the ACH.
Post-Settlement: The R message is sent after a transaction is settled in the ACH.
Settlement
Date
R Message
Initiating
Party
Description
Pre-Settlement
Cancellation
Creditor
Bank
A creditor bank requests to cancel a previously sent
direct debit message by sending a cancellation
message to the ACH.
Pre-Settlement
Rejection
Debtor
Bank
A debtor bank rejects a direct debit message
received from a creditor bank by sending a rejection
message to the ACH.
Pre-Settlement
Refusal
Debtor
Bank
A debtor bank refuses to honor a direct debit
message by sending a refusal message to the ACH.
A debtor bank can refuse to honor a direct debit for a
reason such as an invalid mandate.
Post-Settlement
Reversal
Creditor
Bank
A creditor bank generates a reversal after
determining that a payment was received due to an
invalid direct debit message.
Post-Settlement
Return
Debtor
Bank
A debtor bank returns a direct debit message to a
creditor bank for a reason such as insufficient funds
in the debtor account.
Post-Settlement
Refund
Debtor
Bank
A debtor bank requests a refund from a creditor after
transaction settlement when the debtor disagree to
the direct debit.
1.3.7 Mixed Files
GPP supports mixed file processing for both incoming and outgoing files. A mixed file is a file that
contains both credit transfers and direct debit messages (in addition to related transactions, such as
return messages) in a single file. A mixed file can contain either PAIN or PACS messages, but not
both.
1.4 GPP Message Types Terminology
During GPP mass payment processing, GPP generates the following messages for different purposes
like posting, advising, etc. These message types are used in GPP terminology and during the MP BG
descriptions.
Mass Payments Introduction
Global PAYplus Business Guide Page 10
These messages can be one of the following types:
Type
Message
Details
I
Individual
GPP generates I payment for an individual transaction that was
received in a bulk.
S
Sub-Batch
GPP generates S payment for consolidated payments that share
common attributes like account, request date.
R
R-messages
GPP generates an Individual R payment for rejection, reversal,
recall, refund, return.
A
Aggregation
GPP generates an A payment for the consolidated payments sent
out in a file.
F
Funding
GPP generates an F payment for Inter-office transaction, when the
initiating office differs from the destination office, but both are in
GPP.
RF
Reverse Funding
GPP generates an RF message to reverse F message.
RS
Reverse Sub-Batch
GPP generates an RS message to reverse S message.
Mass Payments Processing
Global PAYplus Business Guide Page 11
2 Processing
This section provides details of the end to end GPP processes describing each step in the Mass
Payments flow. GPP processes incoming and outgoing credit and debit files and R messages.
Note: For a description of the legend used in all the workflows, see Appendix C: Flow Legend.
2.1 Credit Transfer Process
2.1.1 Incoming File Handling
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass payment file, such as a file containing pain.001 or
pain.008 messages.
2.1.1.1 File Processing Workflow
File Processing
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 3 of 35
Start
File
File Parsing/
Validations
Rejected
File Priority File
Duplicate
Check
MatchingCheckService
Sub Type = Orig
File^Duplicate
File
Department
Selection
Create
Batch
Summary
Cont
Mass Payments Processing
Global PAYplus Business Guide Page 12
2.1.1.2 File Parsing/Validations
When GPP receives a mass payments file, GPP:
Parses the file to bulks and validates the format and contents of the file.
o If parsing fails, GPP rejects the file
o If parsing is successful, GPP continues to process the file
Assigns a unique file ID to each received file and registers the file in the File Summary.
Checks that the initiating party (the party who sent the mass payment file) is a customer of the FI.
GPP continues processing a mass payment file only if all file validations succeed.
If an incoming file does not pass file validation, GPP generates a file-level error and does not continue
processing the file. GPP can also generate a payment status report file and send it to the initiating
party to indicate that the file was rejected. The report file includes a reason for the file rejection. For
more information, see Acknowledgment Reporting
2.1.1.3 Create Batch (Payment Information) Summary
Each incoming file received from a customer can contain multiple batches. GPP delimit the batches
by specific parameters, for example:
Debtor Account ID (for credit transfer files)
Execution Date/Due Date
GPP determines specific batch processing preferences using the following:
Batch Control Profile: Enables a bank to define specific file processing preferences for each
batch in an incoming file. For more information, see Batch Control Profile.
Incoming File: Can contain specific batch processing instructions such as batch booking
indicator.
File Processing II
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 4 of 35
Validate
Initiating
Party
Not Valid
InitgPty
Incoming
File Filter
Rules
Rejected
Hold
Split file to
processing
group
(chunks)
Cont
Distributed
Release
Distributed
Business
Flow
Selection
Cancelled
Release
Rejected
Back
Mass Payments Processing
Global PAYplus Business Guide Page 13
Parties Profile: Enables a bank to define specific processing preferences in the Acknowledgment
Preferences section. For more information, see Parties Profile.
GPP users can view information about the batches in a file received from a customer. For more
information, see Batch Summary.
2.1.1.4 File Department Selection
GPP derives and identifies payment attributes (for example, office, department, creation date) during
the initial process in the business flow.
Once the Office is selected, the Department Selection rules for this Office, are evaluated to select the
relevant Department. A default department is selected when there are no specific rules setup.
2.1.1.5 File Priority
The order in which GPP processes each file can be prioritized using the File Priority rules. Each File
Priority rule is attached to a specific office.
After validating an incoming file, when two or more files are waiting for processing, GPP invokes the
File Priority rules to assign a priority to the incoming file. GPP first processes the file with the highest
priority and continues processing subsequent files according to the priority of each, as determined by
the rule. For example, high priority can be assigned to files received from a specific customer.
Each payment in an incoming file inherits its file-level priority.
If a file-level priority is not assigned to an incoming file, GPP determines the payment-level priority for
each payment in the file using Prioritization rules. These rules enable a bank to assign a priority to an
individual payment.
When viewing payments in a manual queue, an authorized GPP user can sort messages by the
assigned priority to assist in handling higher priority payments first.
For File priority Codes, see File Priority Rules.
2.1.1.6 File Duplicate Check
GPP checks whether the incoming file is duplicated and has already been received and processed.
This check is based on parameters which are configurable in GPP (system configuration).
If a duplicate file is found, GPP routes the file to the Duplicate queue for manual handling. A user
can perform one of these actions:
o Release the file to continue processing
o Cancel the file
If a duplicate file is not found; GPP continues to process the payment.
2.1.1.7 Validate Initiating Party
GPP checks that the initiating party is registered for submitting files.
If the Initiating Party is not valid, GPP changes the status of the file to Not Valid Integrity. The user
can perform one of these actions:
o Release the file for continued system processing
o Reject the file
If the Initiating Party is valid; GPP continues to process the payment.
Mass Payments Processing
Global PAYplus Business Guide Page 14
2.1.1.8 Incoming File Filter Rules
GPP invokes Incoming File Filter rules to enable a bank to prevent STP processing of an incoming
file. The Incoming File Filter rules are attached to an initiating party.
If GPP determines that an incoming file meets the conditions defined in an Incoming File Filter rule,
GPP stops processing the file and performs an action defined in the rule. A rule can have one of the
following actions:
Hold: GPP routes the incoming file to a queue for manual handling.
Reject: GPP rejects the incoming file.
Example: A rule is defined that holds all files received from a specific bank customer and routes them
to a queue for manual handling.
In addition to an action definition, each Incoming File Filter rule has an optional usage definition that
enables a bank to define an error code for each incoming file that meets the conditions of the rule.
GPP generates a file-level NAK to the initiating party, which contains error message details as
specified in the business rule.
2.1.1.9 Split File to Processing Group (Chunks)
GPP distributes transactions received in files into manageable group of transactions to increase
system performance and maximize system resource utilization.
After initial validation that includes duplicate checking, GPP distributes the transactions into physical
groups. A system parameter defines the number of individual transactions that GPP includes in each
group.
The GPP mass payment functionality can handle incoming files that contain multiple message types.
A GPP mechanism ensures that all groups are processed in the correct order based on message
type. This prevents illogical processing situations, such as processing a message recall before the
corresponding payment received in the same file.
After distributing incoming transactions into groups, GPP processes each group of transactions using
parallel processing to increase TPS (Transactions per seconds).
The number of running parallel processes is directly related to specific system configuration.
2.1.1.10 Business Flow Selection
For Customers processing Mass Payments, the business flow selection is defaulted to Mass
Payments per customer specific requirements.
2.1.2 Preprocessing Transactions
Once the Payment Information (PaymentInf) is validated successfully, GPP generates the individual
transactions related to the validated Payment Information. Any changes to PaymentInf level
information, as a result of processing within GPP is applied to the related individual transactions (for
example, changes to the initiating party account).
During the pre-processing flow, GPP generates a Unique Grouping ID (UGID) to identify and group
individual transactions that share common attributes. GPP uses the UGID when generating an S
message as part of the mass payment functionality.
Individual transactions that generate errors, such as duplicate transactions, are routed to the Rejected
Duplicate queue.
Mass Payments Processing
Global PAYplus Business Guide Page 15
2.1.2.1 Payment Initiation
For a detailed description of the Payment Initiation, see Payment Initiation Business Guide.
2.1.2.1.1 Payment Initiation Workflow
2.1.2.1.2 Map Payment Information
GPP derives and identifies fundamental payment attributes, for example, Department, and Message
Class, during the initial process in the business flow.
2.1.2.1.3 Rate Usage - Base Conversion
GPP converts all transactions to a base currency equivalent, which enables security checks,
threshold limit checks, and other validations.
2.1.2.1.4 Repair and Enrichment
GPP utilizes the Repair and Enrichment Rules and Repair and Enrichment Selection Rules to
automatically repair messages, which increases STP rates. GPP also enriches specific message
fields by deriving required information.
Transactions can be automatically repaired and enriched using the Repair and Enrichment rules,
which can derive missing information that was not included in the original payment message.
GPP can use these rules to do the following:
Set values of missing transaction attributes
Remove values from transaction attributes
Update transaction statuses
GPP determines the relevant rule by invoking Repair and Enrichment Selection rules for specific
transactions.
Pre Processing - Payment Initiation I (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 5 of 35
Map
Payment
Info
Sets...
MID
Msg Class
Office
Department
Product code etc..
Repair
Submit
Cancel
Rate usage-
base
conversion
Source MOP
STP
Validation
Repair And
Enrichment
Message
Duplicate
Check
MatchingCheckService
Sub Type = OrigInal
Payment^Duplicated
Cont
Party Detail
Enrichment
Bacl
Office SLACrisis Check
Business
Flow
Selection
Flow
Management
Single
Message
Flow
Wait Rate
Submit
Repair
Mass Payments Processing
Global PAYplus Business Guide Page 16
At a determined point in the workflow, GPP invokes a Repair and Enrichment Selection rule that
checks for specific conditions, such as a specific payment message type. If a transaction matches the
defined conditions, GPP invokes the relevant Repair and Enrichment rule, which can perform an
action such as setting a message attribute with a specific value.
For example, GPP can invoke a Repair and Enrichment Selection rule for all pacs.008 payment
messages. The invoked Repair and Enrichment rule can be defined to perform an action such as
removing the values in the creditor agent message attributes.
2.1.2.1.5 Party Detail Enrichment
GPP identifies and loads relevant account information for the first in chain party.
For incoming files received from a customer or from ACH, GPP identifies and loads the first in chain
debit or credit account. GPP applies derived party attributes to all transactions in the batch (ISO
Payment Information block).
2.1.2.1.6 Message Duplicate Check
Duplicate checking is executed on payments that are either received by GPP from external networks
(ACH) or internal applications or are manually entered or handled by a user. Based on the selected
algorithm (key message fields such as message type, currency, amount and beneficiary) GPP
examines every payment for possible duplication.
GPP determines whether a payment is a duplicate using the Automatic Matching Algorithm rule.
If a payment is a duplicate, GPP routes the payment to the Dupex queue for manual handling. A
user can perform one of these actions:
o Accept to continue processing
o Cancel the payment
If a duplicate payment is not found; GPP continues to process the payment.
2.1.2.1.7 Crisis Check
Crisis Check processing is required to hold transactions, which are in process but due to
extraordinary circumstances need to be stopped from processing further. It is intended as a temporary
measure and more permanent parameters should be set to deal with longer term scenarios, for
example, posting restrictions, static data changes, and non-STP rules.
The Crisis Hold rule is applied to all individual transactions, transactions received via bulk files and
across offices. Any transactions meeting filter conditions are stopped from processing further until a
decision is made to continue processing or cancel.
When a Crisis Hold rule that is attached to an object is changed or detached from an object, the
Release Crisis Filter activity will be triggered and payments will be released.
2.1.2.1.8 Source MOP STP Validation
Source MOP selection identifies the debit MOP. For more information, see GPP Payment Initiation
Business Guide.
The Source MOP can be:
Book for files received from Channels
Low Value clearing
GPP perform MOP STP validation for a specific MOP to increase its STP and to adhere to the MOP
and/or clearing rules, for example, SEPA EPC rulebook regulations.
Mass Payments Processing
Global PAYplus Business Guide Page 17
2.1.2.1.9 Office SLA
Ensures as early as possible in the payment processing flow whether the payment may be associated
with a specific SLA profile. For example, not processing the credit transfer file before a certain time of
the day when cross border credits are usually received.
For more information, see GPP Payment Initiation Business Guide.
2.1.2.2 Credit Transfer (Individual) Processing
2.1.2.2.1 Debit Party Workflow
2.1.2.2.1.1 Incoming Return/Reject Matching
GPP automatically attempts to match the incoming R message to its related message using system
configurable criteria as defined in a Matching Check profile. Once matched, authorized users can
view all related messages in the GPP user interface.
For more information, see GPP R-Messages Business Guide.
2.1.2.2.1.2 Find First in Chain
GPP identifies the transaction destination (from where the payment is being sent) for the first party in
the debit chain. When the First in Chain party cannot be identified, the transaction is sent to Repair for
manual handling.
For more information, see GPP Parties Identification Business Guide.
2.1.2.2.1.3 Load Party
GPP identifies and loads relevant account information for the first in debit chain party. If there is an
issue with identifying the party, the transaction is routed to the Repair queue for manual handling.
For more information, see GPP Parties Identification Business Guide.
Pre Processing - Debit Party Processing (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 6 of 35
Back Cont
Find 1st in
Chain Load Party
Repair
Account
Derivation Debit
Authorization SLA- Debit
party
Rate usage
for debit side
conversion
Batch Booking=’False’
Submit
Cancel
Flow
Management
Incoming
Return/
Reject
Matching
Mass Payments Processing
Global PAYplus Business Guide Page 18
2.1.2.2.1.4 Account Derivation
GPP derives relevant accounts (debit account of a credit transfer) and performs currency conversions
(if required) when the payment currency is different to account currency.
If there is an issue with identifying the account, the payment is routed to the Repair queue for manual
handling.
For more information, see GPP Parties Identification Business Guide.
2.1.2.2.1.5 Debit Authorization
Credit Transfer Debit Authorization verifies that the FI is authorized to debit the debtor account. This
is performed on the individual transaction only when posting is performed for each individual
transaction.
For more information, see GPP Parties Identification Business Guide.
2.1.2.2.1.6 SLA Debit Party
Ensures whether the payment is associated with a specific SLA Debit Party profile. For example, not
processing the credit transfer file before a certain time of the day when cross border credits are
usually received.
2.1.2.2.1.7 Rate Usage for Debit Side Conversion
If a currency conversion is required GPP invokes Rate Usage rules to determine the relevant foreign
currency exchange rate for each transaction.
Based on the type of conversion, the following types of Rate Usage Conversion rules may be invoked:
Base Amount Conversion: Determines the base amount foreign currency conversion rate for
transactions.
Debit Side Conversion: Determines the debit-side foreign currency conversion rate for payments.
For more information, see GPP Currency Conversion Business Guide.
2.1.2.2.2 Credit Side Workflow
Pre Processing - Credit Side Processing (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 7 of 35
Start
Credit Party
Processing
Repair
Dest MOP
STP
Validation
Submit
Cancel
Cont
Party Detail
Enrichment
Multi Office
– Re invoke
Destination
Party
Flow
Management
Transfer
method
identification
Applicable for bank routing
Mass Payments Processing
Global PAYplus Business Guide Page 19
2.1.2.2.2.1 Credit Party Processing
During the credit party processing, GPP identifies the first in the credit chain, loads the party and the
credit account.
For more information, see GPP Parties Identification Business Guide.
2.1.2.2.2.2 Party Detail Enrichment
GPP identifies and loads relevant account information for the first party in the chain - credit side of a
credit transfer.
GPP invokes Credit Account Enrichment rules to determine the credit account number and usage
instructions for that account for Credit Transfer. These rules enable a FI to define the relevant credit
account for a payment.
2.1.2.2.2.3 Destination MOP Selection and MOP STP Validation
GPP uses Method of Payment (MOP) selection rules defined in GPP, to determine the best route for
the payment to be delivered, for example, via clearing, SWIFT. The MOP parameters are also used to
determine whether the transaction continues processing as a single message or should be sent out in
a file.
For more information, see GPP Method of Payment Business Guide.
2.1.2.2.2.4 Transfer Method Identification
This step is relevant for transactions received in a file and executed via High Value/Individual
processing. During this process, GPP indicates if the transaction’s transfer method is Serial or Cover.
For more information, see GPP Building Correspondent Chain Business Guide.
2.1.2.2.2.5 Multi Office - Re Invoke Destination Party
In a multi office scenario where the creditor is located in a different office than the debtor, the credit
side is re-processed and re-evaluates all the rules in the destination office.
Mass Payments Processing
Global PAYplus Business Guide Page 20
2.1.2.3 Post MOP
2.1.2.3.1 Post MOP Workflow
2.1.2.3.2 Debit Transaction Code
In this process GPP selects a debit code per transaction. This code can be exposed for external
systems in a structured way. Examples of the code are type of transaction, type of customer, and
fees.
2.1.2.3.3 Credit Transaction Code
In this process GPP selects a credit code per transaction. This code can be exposed for external
systems in a structured way. Examples of the code are type of transaction, type of customer, and
fees.
2.1.2.3.4 Prevent STP
GPP uses Override STP profiles to prevent Straight-Through Processing (STP) of specific payments.
The Override STP profile can be defined for the following:
Special Instruction: Prevent STP processing of a payment with specific characteristics, such as a
settlement amount greater than a defined value.
Validation: Prevent STP processing of a payment that is invalid as defined by the specific
conditions, such as a missing product code.
For a list of error statuses, see Appendix B: STP Validation Error Statuses.
For more information, see GPP Special Instructions Business Guide.
2.1.2.3.5 Fees (Itemized)
The relevant fees are determined for each party in the transaction. This is performed when posting is
required on the transaction level (Batch Booking is false).
Pre Processing - Post MOP (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 8 of 35
Compliance
Validation
Cont
Debit
Transaction
code
Credit
Transaction
code Prevent STP Generate Sub
Batch
Wait Sub-
Batch
Wait
Sched Sub
Batch
Processing
date
Cancel
Start
Accumulate transaction
according to grouping ID
Batch compliance request
Compliance
request - file
buffer
Fees
(itemized)
Batch Booking=’False’
Flow
Management
Future
Date
Mass Payments Processing
Global PAYplus Business Guide Page 21
For more information, see GPP Fees - Core Processing Business Guide
2.1.2.3.6 Compliance Validation
GPP invokes Compliance Validation rules to determine whether to send a specific payment for
compliance to verify that a payment complies with various anti-money laundering regulations.
GPP enables the following types of Compliance Validation rules:
Submit: If a payment meets the conditions defined in the rule, GPP sends the transaction for
compliance verification.
Bypass: If a payment does not meet the conditions defined in the rule, GPP does not send the
transaction for compliance verification.
2.1.2.3.7 Generate Grouped Transaction (Sub Batch)
As part of this processing GPP groups number of payments which have similar parameters in order to
allow single posting on the account or perform single currency conversion for the entire S message.
When GPP completes preprocessing for all individual transactions, additional file validations are
invoked as follows:
Number of Transactions: Validates that the total number of transactions counted in an incoming
file matches the declared number of transactions in the file.
Control Sum: Validates that the total amount of all transactions contained in the incoming file is
equal to the amount defined in the file header. GPP includes all payment amounts when checking
the control sum, regardless of the defined currency for an individual transaction.
Rejected Transactions: Validates that the total number of transactions (expressed as a
percentage) in an incoming file that are rejected by GPP does not exceed a threshold set by the
bank.
Transactions that successfully complete these file validations continue to be processed in the Sub-
Batch Generation.
If the additional validations are not successful, GPP stops processing the transactions, and might hold
the file for manual handling or reject it.
2.1.3 Payment Grouping (Sub Batch) Generation
Sub-Batch generation accumulates transactions that are sent out in files and completes processing
on individual transactions.
GPP collects and group transactions originated in a file into groups based on definable criteria in
order to apply actions on the entire group for example, posting, fees, and foreign exchange.
Mass Payments Processing
Global PAYplus Business Guide Page 22
2.1.3.1 Sub Batch Generation (S) Workflow
Sub Batch Generation (S)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 9 of 35
Debit
Authorization
Rate usage
for debit side
conversion
Debit
Transaction
Codes
Fees
(Sub-Batch)
Credit
Transaction
code
Value Date
Start Cont
Recalculate Value Date
Batch Booking=’True’ Batch Booking=’True’
Sub Batch Generation II (S)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 10 of 35
Posting-
consolidated
(first leg)
Flow
Management
Complete
Debit hold
until time
Back Cont
Schedule
Stop Flag
Interface
Selection
Balance
Inquiry
Wait BI
Force
NSF
Retry
External FX
(Lump Sum)
FX Engine
Interface
Compliance
Check
Future Dated
Wait FX
FX Repair
Submit
Flow
Management
Flow
Management
Mass Payments Processing
Global PAYplus Business Guide Page 23
2.1.3.2 Debit Authorization
Debit Authorization verifies that the FI is authorized to debit the debtor account. This is performed on
the S message only when posting is required to be performed for the S message (Batch Booking flag
is true).
For more information, see GPP Parties Identification Business Guide.
2.1.3.3 Rate Usage for Debit Side Conversion
GPP uses Rate Usage rules to determine the relevant foreign currency exchange rate for each
transaction, if a currency conversion is required.
The Debit Side Conversion determines the debit-side foreign currency conversion rate for
transactions.
2.1.3.4 Value Date
GPP recalculates the Value Date for the S message.
For more information, see Value Date and Cutoff Business Guide.
2.1.3.5 Debit Transaction Code
In this process GPP selects a debit code per transaction. This code can be exposed for external
systems in a structured way. Examples of the code are type of transaction, type of customer, fees.
2.1.3.6 Credit Transaction Code
In this process GPP selects a credit code per transaction. This code can be exposed for external
systems in a structured way. Examples of the code are type of transaction, type of customer, fees.
2.1.3.7 Fees (Sub Batch)
The relevant fees are determined for each party in the S message. This is performed if posting is
done on the S message (Batch Booking flag is true).
For more information, see Fees – Core Processing Business Guide.
2.1.3.8 Debit Hold Until Time
GPP provides a mechanism of stopping S message processing up until a pre-defined time. This is
performed using the Hold Until Time rule. When a rule is selected to a sub batch, based on specific
attribute, the sub batch is held until a pre-defined time (and as a result, all of the transactions related
to the Sub batch are held until its completion). On the selected time, Sub batch is released back to
processing.
2.1.3.9 Interface Selection
GPP uses Interface Selection rules to interact with external interfaces at specific stages during the
payment processing. At this stage the Balance Inquiry Interface can be selected.
If GPP determines that a payment matches the defined rule conditions, the defined action of the rule
is executed, which can be one of the following:
Bulk Interface Request: Message attributes are accumulated and stored, which GPP later uses
to generate a bulk request to an external interface.
Individual Interface Request: Individual message attributes are stored and GPP generates a
single request to an external interface.
Mass Payments Processing
Global PAYplus Business Guide Page 24
The action for an Interface Selection rule implements an Interface profile that includes definitions for
interface requests and responses such as:
Protocol: The protocol used by GPP to communicate with the external interface.
Format Type: The format of the incoming response or outgoing request.
Connection Point: The location of the request that is sent or of the response that is received.
2.1.3.10 Stop Flag
Account stop flag check is performed on the S message account. The stop flag is either received from
Balance Inquiry response or setup in the account profile.
2.1.3.11 Compliance Check
A GPP Compliance service ensures compliance with various anti-money laundering regulations and
foreign asset controls. GPP verifies that all incoming and outgoing payments in the S message
comply with the latest regulations, such as embargoes and anti-terrorist financing regulations.
GPP performs the compliance check in a two-step process:
1. Initial Response: GPP sends an initial request to the compliance interface, for all transactions in
the bulk as a single request. The interface returns one of the following types of Initial Responses:
o No Hit: The interface determines that the payment complies with all relevant regulations. GPP
continues processing the payment.
o Possible Hit: The interface determines that the payment might not comply with all relevant
regulations. GPP does not continue processing the payment. It is pending receipt of a Final
Response.
2. Final Response: The interface returns one of the following types of Final Responses:
o Passed: The interface determines that the payment complies with all relevant regulations.
GPP continues processing the payment.
o Rejected: The interface determines that the payment does not comply with all relevant
regulations and returns a rejected indicator. GPP rejects the payment by setting the payment
status to Rejected and routing the message to the Rejected queue. GPP does not continue
processing the message.
o Seized: The interface determines that the payment does not comply with all relevant
regulations and returns a seized indicator. GPP implements a process to seize the payment
by setting the payment status to Seized and routing the message to the Seized queue. This is
a final status and GPP does not continue processing the message.
2.1.3.12 External FX (Lump Sum)
GPP Performs currency conversion for the lump sum amount when the payment currency is different
to the account currency. .
GPP calculate conversions using an FX rate obtained from GPP or using a rate from an external
system.
2.1.3.13 Posting Consolidation (First Leg)
GPP triggers the relevant interface to perform required posting.
In a credit transfer, debits the debtor or clearing participant and credits the relevant suspense
account.
Mass Payments Processing
Global PAYplus Business Guide Page 25
2.1.3.14 Flow Management
As part of the flow management the S message is routed to Complete after posting and GPP
continues the execution processing on the individual transactions.
2.1.4 Execution
GPP generates posting and processes the outgoing file during the execution stage. GPP performs a
few generic steps and then based on bulking profile existence, GPP process individual executions
and bulk executions.
2.1.4.1 Execution Workflow
2.1.4.2 Hold Until Time
GPP provides a mechanism of stopping selected transaction processing up until a pre-defined time.
This is performed using the Timed Hold rule. When a rule is selected to a sub batch, based on
specific attribute, the sub batch is held until a pre-defined time (and as a result, all of the transactions
related to the Sub batch are held until its completion). On the selected time, Sub batch is released
back to processing.
2.1.4.3 Interface Selection (Balance Inquiry)
GPP uses the interface selection rules to generate an external balance inquiry request. For Balance
Inquiry standard interface information, see GPP Technical Guide Balance Inquiry Interface.
2.1.4.4 Stop Flag
Account stop flag check is performed on the individual account. The stop flag is either received from a
Balance Inquiry response or setup in the account profile.
Execution (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 11 of 35
Posting-
itemized
(customer
leg)
Stop Flag
Batch Booking= ‘False’
Bulking Profile
Exists
Back
Hold Until
Time
Execution -
Individuals
Execution -
Bulking
Profile
Interface
Selection
Balance
Inquiry
Wait BI
Force
NSF
Retry
Schedule
External FX
(Individual)
FX Engine
Interface
Compliance
Check
Future Dated
Wait FX
FX Repair
Submit
No Bulking
Profile
Flow
Management
Flow
Management
Hold
Flow
Management
Batch Booking= ‘False’
Mass Payments Processing
Global PAYplus Business Guide Page 26
2.1.4.5 Compliance Check
GPP performs a compliance request on the individual payment.
2.1.4.6 External FX (Individual)
GPP generates an external FX request for individual payments, when posting indicator refers to
individual payments.
2.1.4.7 Posting Itemized (Customer Leg)
GPP triggers the relevant interface to perform required posting. For example for CTO GPP perform
the debit posting per transaction.
For more information, see Mass Payments Accounting
2.1.5 Execute Individual
During this process, GPP process individual executions.
2.1.5.1 Execute Individual Files Workflow
2.1.5.2 Liquidity
In this step, GPP checks the liquidity status for clearing the settlement account.
For more information, see GPP Liquidity & Risk Management Business Guide
2.1.5.3 Posting (Individual Credit)
GPP triggers the relevant interface to perform the required posting.
For more information, see Mass Payments Accounting
Execution - Destination Single (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 12 of 35
Posting
(Individual
Credit)
Format Out
And
Transmission End
CTO
Negative
Response
Flow
CTO
Positive
Response
Flow
Positive
Match
Response to
Payment
Service
Release
Unmatched
Flow
Management
Liquidity
Back Negative
Mass Payments Processing
Global PAYplus Business Guide Page 27
2.1.5.4 Format Out and Transmission
GPP generates the out payment.
2.1.5.5 Match Response to Payment
GPP matches the response to the individual payment
2.1.5.6 Response Handling
2.1.5.6.1 CTO Negative Response
Upon receipt of a negative response, the CTO is routed to the Rejected queue.
2.1.5.6.2 CTO Positive Response
Upon receipt of a positive response, the CTO remains in the Complete queue.
2.1.6 Execute Bulk Destination
GPP collects and organizes transactions destined for a file-based clearing system into bulks based on
definable criteria. An outgoing file can contain multiple message types. For example, a single
outgoing file can contain credit transfers, recall requests, and recall returns. An outgoing file can also
contain transactions that were received individually and transactions that were received in files.
GPP uses the specific bulking parameters for each Method of Payment (MOP) that handles
transaction bulking. These parameters are defined in the Bulking profile that is associated with the
MOP.
2.1.6.1 Execute Bulk Workflow
Execution - Destination Bulk (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 13 of 35
Out bulk
grouping ID
selection
Bulking
sending time
Posting
(Individual
Credit)
Consolidated
Accounting=No
Out File
Generation
Complete
Generate ‘A’ message
based on following fields
- MOP
- Sttlm Acct
- Sttlm Dt
Back
Posting
(Consolidated
Credit)
Consolidated
Accounting=Yes
Flow
Management Response
Handling
Match
Response to
Payment
End
Mass Payments Processing
Global PAYplus Business Guide Page 28
2.1.6.2 Out Bulk Grouping ID Selection
GPP invokes Out Bulk Grouping ID Selection rules to determine the Group ID - Out data manipulation
rule that GPP uses to build the OFID, and OGID.
The OFID (outgoing file ID) is used to place transactions into the relevant outgoing file.
The OGID (outgoing group ID) is used to place transactions with common attributes into relevant
groups in the outgoing file.
When generating an outgoing customer file (pain.001 and pain.008), GPP determines:
1. The relevant file into which the transaction should be placed using the OFID. The OFID
determines, for example, if a file must only contain transactions of a single message type or value
date.
2. The relevant Group Header within the outgoing file into which the transaction should be placed
using the OGID.
2.1.6.3 Bulking Sending Time
GPP invokes Bulking Sending Time rules to determine the appropriate time to generate and send
outgoing files of payment messages. Each sending time defined in the Bulking profile must have a
corresponding Bulking Sending Time rule.
This rule also enables authorized GPP users to define a last sending time for a specific message
type.
Bulking profile can be configured to send out the relevant transaction upon incoming file processing.
In this case, Bulking sending time rules are not evaluated and Out file generation is triggered once
incoming file processing is completed (i.e. all transactions received in the incoming file are
processed).
2.1.6.4 Posting (individual Credit)
GPP triggers the relevant interface to perform required posting.
For more information, see Mass Payments Accounting.
2.1.6.5 Flow Management
GPP routes all individual transactions to the Complete queue and creates the A message for file
generation.
2.1.6.6 Out File Generation
GPP invokes Bulking Sending Time rules to determine the time to generate and send outgoing files of
payments. Each sending time defined in the Bulking profile must have a corresponding Bulking
Sending Time rule.
This rule also enables authorized GPP users to define a last sending time for a specific message
type.
For more information about Bulking profiles and sending times, see Bulking Profile.
GPP also enables authorized users to generate outgoing files containing groups of transactions that
have successfully completed processing and send them to a CSM, regardless of the defined sending
time. For more information, see Pending Outgoing File.
Mass Payments Processing
Global PAYplus Business Guide Page 29
2.1.6.7 Posting (Consolidated Credit)
GPP triggers the relevant interface to perform required posting.
For more information, see Mass Payments Accounting
2.1.6.8 Match Response to Payment
GPP matches the response to the file level.
2.1.6.9 Response Handling
2.1.6.9.1 CTO Negative Response
Upon receipt of a negative response, the CTO is routed to the Rejected queue.
2.1.6.9.2 CTO Positive Response
Upon receipt of a positive response, the CTO remains in the Complete queue.
2.1.7 Acknowledgment Reporting
GPP can generate file status reports for FI customers that enable the customers to track file and
transaction processing. GPP can generate these reports at different stages of the processing
workflow using Advising Type Selection rules. For more information about the rule, see Advising Type
Selection Rules.
GPP enables a bank to generate a Customer Acknowledgment report for a customer. The report is a
file that contains details of all accepted and rejected transactions for a customer that a bank receives
in a single file. GPP generates a Customer Acknowledgment upon completion of individual
transaction validation during the specific payment processing workflows and stores it in a specific
location, after which an external interface sends it to the initiating party (bank customer).
GPP generates the following types of acknowledgments (both in pain.002 format):
ACK: A positive acknowledgment message
NAK: A negative acknowledgment message
The Parties profile enables a bank to define the types and XSD versions of acknowledgment
messages that GPP generates for each customer. For more information, see Parties Profile.
GPP invokes Advising Type Selection rules to determine whether an advice message must be
generated at a specific point in the workflow. For example, this rule type is used to generate file-level
acknowledgments or message acknowledgments in response to a file received file from a corporate
customer.
Predefined rules are included to generate a pain.002 acknowledgment message to an initiating party
that sent a mass payment file and is defined to receive a Customer Acknowledgment (see Parties
Profile) when the following occur:
File Rejected by User: If a file does not pass validation (see File Parsing/Validations), GPP can
hold it for manual handling. If an authorized GPP user chooses to reject the file, GPP generates
an advice message file with an RJCT file rejection code. Individual transactions are not included
in the file.
Preprocessing: During Preprocessing (see Preprocessing Transactions), GPP accumulates
information for the following:
Mass Payments Processing
Global PAYplus Business Guide Page 30
o Positive Acknowledgments: Generated for successfully processed transactions
o Negative Acknowledgments: Generated for transactions that failed processing, each advice
message includes a reason for the failure
Additional File Validation and Request File Generation: During the process, GPP performs
additional file validations, which can result in the following:
o Complete or Partial File Acceptance: If a file passes additional file validations, completely or
partially, GPP generates an acknowledgment file in pain.002 format. The file contains
accumulated information for each individual transaction with an ACTC reason code for each
accepted transaction and an RJCT reason code for each rejected transaction.
o File Rejection: If a file does not pass additional file validations, GPP rejects the entire file, sets
the file rejection code to RJCT, and generates a file-level rejection. The file does not contain
individual transactions.
Sub-Batch: During the Sub-Batch flow, GPP invokes Advising Type Selection rules to generate
an individual pain.002 NAK for each transaction that received a negative compliance response.
For more information about the GPP Compliance Service, see Compliance Check.
The Advising Type Selection rules can also be used to set up event notifications when the information
provided in each event is by a predetermined structure, such as a configurable XML tag or value.
2.1.8 Mass Payments Accounting
2.1.8.1 Outward Credit Transfer Accounting Models
GPP generates a single or consolidated posting.
When a file of credit transfers is received from a corporate customer, GPP can perform a consolidated
debit to the debtor’s account. Consolidated postings, are offset against a suspense account. When
the transactions are sent out, for example, to clearing, GPP debits the same suspense account
previously credited and credits a clearing account.
Accounting Model
Description
Exceptions Scenarios
Customer Leg
(Debit
Customer)
Itemized
For each transaction within a
file, individual posting entries
and accounting requests will
be generated.
Any payments
rejected/cancelled at a
later stage perform
reverse accounting
Consolidated Net
Accounting
Performs lump sum
accounting (debit customer)
for processed transactions
only (for example,
transactions which
successfully completed pre-
processing)
Posting is not performed for
rejected or canceled
transactions.
Payments included in the
lump sum posting, and
rejected/cancelled at a
later stage are posted
separately as offsets to
the account (reverse
accounting)
Consolidated
Gross Accounting
Performs Lump sum
accounting which debits
customer for all transactions
which were not rejected
during pre-processing.
For example, transactions
which completed pre-
processing/in repair/
sanctions hold.
Any payments
rejected/cancelled after
posting are posted
separately as offsets to
the account (reverse
accounting).
Mass Payments Processing
Global PAYplus Business Guide Page 31
Accounting Model
Description
Exceptions Scenarios
Clearing
Leg/Book
(Credit
Settlement
account)
Itemized
For each transaction,
individual posting entries and
accounting requests are
generated to credit the
settlement account /
customer.
Rejected/cancelled
payments perform
reverse accounting.
Consolidated
Credit - Gross
GPP performs consolidated
credit-side posting, in which
posting debits the relevant
suspense account and
credits the clearing account
associated with the MOP.
Any payments rejected
by the scheme are
posted separately as
offsets to the account
(reverse accounting).
2.1.8.2 Inward Credit Transfer Accounting Models
Accounting Model
Description
Exceptions Scenarios
Clearing Leg
(Debit
Settlement
account)
Itemized
Any payment
rejected/cancelled at a later
stage performs reverse
accounting.
Any payments
rejected/cancelled at a
later stage perform
reverse accounting.
Consolidated
Gross Accounting
Lump sum accounting debits
settlement account for lump
sum amount of all
transactions received from
the clearing.
Any payments rejected at
a later stage are posted
separately as offsets to
the account (reverse
accounting).
Customer Leg
(Credit
Customer)
Itemized
For each transaction within a
file, individual posting entries
and accounting requests are
generated to credit the
customers.
Consolidated
Credit - Gross
GPP performs consolidated
credit-side posting, in which
posting debits the relevant
suspense account and
credits the clearing account
associated with the MOP.
Any payments rejected
by the scheme are
posted separately as
offsets to the account
(reverse accounting).
2.2 Direct Debit Process
2.2.1 Incoming File Handling
GPP receives and processes incoming files that contain transaction messages.
Processing begins upon the receipt of a mass payment file, such as a file containing pain.001 or
pain.008 messages.
Mass Payments Processing
Global PAYplus Business Guide Page 32
2.2.1.1 File Processing Workflow
File Processing
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 3 of 35
Start
File
File Parsing/
Validations
Rejected
File Priority File
Duplicate
Check
MatchingCheckService
Sub Type = Orig
File^Duplicate
File
Department
Selection
Create
Batch
Summary
Cont
File Processing II
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 4 of 35
Validate
Initiating
Party
Not Valid
InitgPty
Incoming
File Filter
Rules
Rejected
Hold
Split file to
processing
group
(chunks)
Cont
Distributed
Release
Distributed
Business
Flow
Selection
Cancelled
Release
Rejected
Back
Mass Payments Processing
Global PAYplus Business Guide Page 33
2.2.1.2 File Parsing/Validations
When GPP receives a mass payments file, GPP:
Parses the file to bulks and validates the format and contents of the file.
o If parsing fails, GPP rejects the file
o If parsing is successful, GPP continues to process the file
Assigns a unique file ID to each received file and registers the file in the File Summary.
Checks that the initiating party (the party who sent the mass payment file) is a customer of the FI.
GPP continues processing a mass payment file only if all file validations succeed.
If an incoming file does not pass file validation, GPP generates a file-level error and does not continue
processing the file. GPP can also generate a payment status report file and send it to the initiating
party to indicate that the file was rejected. The report file includes a reason for the file rejection. For
more information, see Acknowledgment Reporting
2.2.1.3 Create Batch (Payment Information) Summary
Each incoming file received from a customer can contain multiple batches. GPP delimit the batches
by specific parameters, for example:
Creditor Account ID (for direct debit files)
Execution Date/Due Date
GPP determines specific batch processing preferences using the following:
Batch Control Profile: Enables a bank to define specific file processing preferences for each
batch in an incoming file. For more information, see Batch Control Profile.
Incoming File: Can contain specific batch processing instructions such as batch booking
indicator.
Parties Profile: Enables a bank to define specific processing preferences in the Acknowledgment
Preferences section. For more information, see Parties Profile.
GPP users can view information about the batches in a file received from a customer. For more
information, see Batch Summary.
2.2.1.4 File Department Selection
GPP derives and identifies payment attributes (for example, office, department, creation date) during
the initial process in the business flow.
Once the Office is selected, the Department Selection rules for this Office, are evaluated to select the
relevant Department. A default department is selected when there are no specific rules setup.
2.2.1.5 File Priority
The order in which GPP processes each file can be prioritized using the File Priority rules. Each File
Priority rule is attached to a specific office.
After validating an incoming file, when two or more files are waiting for processing, GPP invokes the
File Priority rules to assign a priority to the incoming file. GPP first processes the file with the highest
priority and continues processing subsequent files according to the priority of each, as determined by
the rule. For example, high priority can be assigned to files received from a specific customer.
Each payment in an incoming file inherits its file-level priority.
Mass Payments Processing
Global PAYplus Business Guide Page 34
If a file-level priority is not assigned to an incoming file, GPP determines the payment-level priority for
each payment in the file using Prioritization rules. These rules enable a bank to assign a priority to an
individual payment.
When viewing payments in a manual queue, an authorized GPP user can sort messages by the
assigned priority to assist in handling higher priority payments first.
For File priority Codes, see File Priority Rules.
2.2.1.6 File Duplicate Check
GPP checks whether the incoming file is duplicated and has already been received and processed.
This check is based on parameters which are configurable in GPP (system configuration).
If a duplicate file is found, GPP routes the file to the Duplicate queue for manual handling. A user
can perform one of these actions:
o Release the file to continue processing
o Cancel the file
If a duplicate file is not found; GPP continues to process the payment.
2.2.1.7 Validate Initiating Party
GPP checks that the initiating party is registered for submitting files.
If the Initiating Party is not valid, GPP changes the status of the file to Not Valid Integrity. The user
can perform one of these actions:
o Release the file for continued system processing
o Reject the file
If the Initiating Party is valid; GPP continues to process the payment.
2.2.1.8 Incoming File Filter Rules
GPP invokes Incoming File Filter rules to enable a bank to prevent STP processing of an incoming
file. The Incoming File Filter rules are attached to an initiating party.
If GPP determines that an incoming file meets the conditions defined in an Incoming File Filter rule,
GPP stops processing the file and performs an action defined in the rule. A rule can have one of the
following actions:
Hold: GPP routes the incoming file to a queue for manual handling.
Reject: GPP rejects the incoming file.
Example: A rule is defined that holds all files received from a specific bank customer and routes them
to a queue for manual handling.
In addition to an action definition, each Incoming File Filter rule has an optional usage definition that
enables a bank to define an error code for each incoming file that meets the conditions of the rule.
GPP generates a file-level NAK to the initiating party, which contains error message details as
specified in the business rule.
2.2.1.9 Split File to Processing Group (Chunks)
GPP distributes transactions received in files into manageable group of transactions to increase
system performance and maximize system resource utilization.
Mass Payments Processing
Global PAYplus Business Guide Page 35
After initial validation that includes duplicate checking, GPP distributes the transactions into physical
groups. A system parameter defines the number of individual transactions that GPP includes in each
group.
The GPP mass payment functionality can handle incoming files that contain multiple message types.
A GPP mechanism ensures that all groups are processed in the correct order based on message
type. This prevents illogical processing situations, such as processing a message recall before the
corresponding payment received in the same file.
After distributing incoming transactions into groups, GPP processes each group of transactions using
parallel processing to increase TPS (Transactions per seconds).
The number of running parallel processes is directly related to specific system configuration.
2.2.1.10 Business Flow Selection
For Customers processing Mass Payments, the business flow selection rule is defaulted to Mass
Payments per customer specific requirements.
2.2.2 Preprocessing Transactions
Once the Payment Information (PaymentInf) is validated successfully, GPP generates the individual
transactions related to the validated Payment Information. Any changes to PaymentInf level
information, as a result of processing within GPP is applied to the related individual transactions (for
example, changes to the initiating party account).
During the pre-processing flow, GPP generates a Unique Grouping ID (UGID) to identify and group
individual transactions that share common attributes. GPP uses the UGID when generating an S
message as part of the mass payment functionality.
Individual transactions that generate errors, such as duplicate transactions, are routed to the Rejected
Duplicate queue.
2.2.2.1 Payment Initiation
For a detailed description of the Payment Initiation, see Payment Initiation Business Guide.
Mass Payments Processing
Global PAYplus Business Guide Page 36
2.2.2.1.1 Payment Initiation Workflow
2.2.2.1.2 Map Payment Information
GPP derives and identifies fundamental payment attributes, for example, Department, and Message
Class, during the initial process in the business flow.
2.2.2.1.3 Rate Usage - Base Conversion
GPP converts all transactions to a base currency equivalent, which enables security checks,
threshold limit checks, and other validations.
2.2.2.1.4 Repair and Enrichment
GPP utilizes the Repair and Enrichment Rules and Repair and Enrichment Selection Rules to
automatically repair messages, which increases STP rates. GPP also enriches specific message
fields by deriving required information.
Transactions can be automatically repaired and enriched using the Repair and Enrichment rules,
which can derive missing information that was not included in the original payment message.
GPP can use these rules to do the following:
Set values of missing transaction attributes
Remove values from transaction attributes
Update transaction statuses and direct debit mandate statuses
GPP determines the relevant rule by invoking Repair and Enrichment Selection rules for specific
transactions.
At a determined point in the workflow, GPP invokes a Repair and Enrichment Selection rule that
checks for specific conditions, such as a specific payment message type. If a transaction matches the
Pre Processing - Payment Initiation I (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 5 of 35
Map
Payment
Info
Sets...
MID
Msg Class
Office
Department
Product code etc..
Repair
Submit
Cancel
Rate usage-
base
conversion
Source MOP
STP
Validation
Repair And
Enrichment
Message
Duplicate
Check
MatchingCheckService
Sub Type = OrigInal
Payment^Duplicated
Cont
Party Detail
Enrichment
Bacl
Office SLACrisis Check
Business
Flow
Selection
Flow
Management
Single
Message
Flow
Wait Rate
Submit
Repair
Mass Payments Processing
Global PAYplus Business Guide Page 37
defined conditions, GPP invokes the relevant Repair and Enrichment rule, which can perform an
action such as setting a message attribute with a specific value.
For example, GPP can invoke a Repair and Enrichment Selection rule for all pacs.008 payment
messages. The invoked Repair and Enrichment rule can be defined to perform an action such as
removing the values in the creditor agent message attributes.
2.2.2.1.5 Party Detail Enrichment
GPP identifies and loads relevant account information for the first in chain party.
For incoming files received from a customer or from ACH, GPP identifies and loads the first in chain
debit or credit account. GPP applies derived party attributes to all transactions in the batch (ISO
Payment Information block).
2.2.2.1.6 Message Duplicate Check
Duplicate checking is executed on payments that are either received by GPP from external networks
(ACH) or internal applications or are manually entered or handled by a user. Based on the selected
algorithm (key message fields such as message type, currency, amount and beneficiary) GPP
examines every payment for possible duplication.
GPP determines whether a payment is a duplicate using the Automatic Matching Algorithm rule.
If a payment is a duplicate, GPP routes the payment to the Dupex queue for manual handling. A
user can perform one of these actions:
o Accept to continue processing
o Cancel the payment
If a duplicate payment is not found; GPP continues to process the payment.
2.2.2.1.7 Crisis Check
Crisis Check processing is required to hold transactions, which are in process but due to
extraordinary circumstances need to be stopped from processing further. It is intended as a temporary
measure and more permanent parameters should be set to deal with longer term scenarios, for
example, posting restrictions, static data changes, and non-STP rules.
The Crisis Hold rule is applied to all individual transactions, transactions received via bulk files and
across offices. Any transactions meeting filter conditions are stopped from processing further until a
decision is made to continue processing or cancel.
When a Crisis Hold rule that is attached to an object is changed or detached from an object, the
Release Crisis Filter activity will be triggered and payments will be released.
2.2.2.1.8 Source MOP STP Validation
Source MOP selection identifies the debit MOP. For more information, see GPP Payment Initiation
Business Guide.
The Source MOP can be:
Book for files received from Channels
Low Value clearing
GPP perform MOP STP validation for a specific MOP to increase its STP and to adhere to the MOP
and/or clearing rules, for example, SEPA EPC rulebook regulations.
Mass Payments Processing
Global PAYplus Business Guide Page 38
2.2.2.1.9 Office SLA
Ensures as early as possible in the payment processing flow whether the payment may be associated
with a specific SLA profile. For example, not processing the direct debit file before a specific time of
the day when cross border debits are usually received.
For more information, see GPP Payment Initiation Business Guide.
2.2.2.2 Direct Debit (Individual) Processing
2.2.2.2.1 Credit Party Workflow
2.2.2.2.1.1 Find First in Chain
GPP identifies from where the payment is being sent for the first party in the credit chain. When the
First in Chain party cannot be identified, the transaction is sent to Repair for manual handling.
For more information, see GPP Parties Identification Business Guide.
2.2.2.2.1.2 Load Party
GPP identifies and loads relevant account information for the first in debit chain party. If there is an
issue with identifying the party, the payment is routed to the Repair queue for manual handling.
For more information, see GPP Parties Identification Business Guide.
2.2.2.2.1.3 Account Derivation
GPP derives relevant accounts (credit account of a direct debit) and performs currency conversions (if
required) when the payment currency is different to the account currency.
If there is an issue with identifying the account, the payment is routed to the Repair queue for manual
handling.
For more information, see GPP Parties Identification Business Guide.
2.2.2.2.1.4 Creditor ID Validation (Outgoing Flow)
Pre Processing - Credit Party Processing (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 6 of 34
Back Cont
Find 1st in
Chain Load Party
Repair
Account
Derivation SLA- Credit
party
Rate usage
for credit side
conversion
Submit
Cancel
Flow
Management
Mandate
Validation
and
Enrichment
If creditor mandate check is
required
Mass Payments Processing
Global PAYplus Business Guide Page 39
The unique CID enables GPP to identify a creditor as part of the mass payment direct debit
functionality.
The CID also enables debtors and debtor Financial Institutions to do the following:
Check for a valid mandate
Identify a creditor to execute a debit refund
GPP invokes the CID Validation when a CID is input or accessed. For example, when a user creates
or updates a profile that contains a CID, such as a Creditor Account profile.
During CID validation, GPP searches for and selects the relevant Creditor ID Structure profile and
does the following:
Validates that the CID does not exceed the defined maximum length
Checks for optional discretionary data included in the CID
Derives the CID key, which is the CID without discretionary data
Validates the CID using the defined check digit algorithm
The CID Validation indicate if the CID is valid or invalid. When the CID is invalid, an error message is
generated.
The invoking process is responsible for handling the returned information correctly. For example:
If a GPP user types an invalid CID, the user interface displays an error message and prevents the
user from creating or updating the relevant profile.
If an incoming direct debit message contains an invalid CID, GPP stops processing the message
and automatically rejects it.
GPP validates that a CID is structured for the debit MOP in an outgoing direct debit message and
validates that the required relationships between a scheme, party, and CID exist in GPP, as defined in
the Creditor ID Structure and Creditor ID profiles.
GPP attempts to identify the Parameters profile using the relevant scheme, party, and CID key in the
following order of priority:
1. Scheme, party code, and CID
2. Scheme and party code
3. Party code only
4. Scheme only
If GPP cannot identify a matching Parameters profile, an error message is returned and GPP does
not continue to process the direct debit.
Upon identifying a matching Parameters profile, which defines the level of validation, GPP performs
one of the following:
No Validation: No additional validations are performed and the CID Processing service is
terminated.
Validate Creditor ID: GPP verifies that the CID is defined for the relevant party code, returns an
error message if the CID is not defined, and terminates the service.
Validate Creditor ID Account: GPP verifies that the CID is defined for the relevant creditor ID
account, returns an error message if the CID is not defined, and terminates the service.
Upon termination, the service returns one of the following:
Mass Payments Processing
Global PAYplus Business Guide Page 40
A successful validation indicator
An unsuccessful validation indicator and an error message
2.2.2.2.1.5 Mandate Validation and Enrichment
Mandate validation is performed on the creditor side only if a creditor mandate check is required.
GPP validates on the creditor side that a mandate exists. If a mandate exists between the relevant
parties, the following validations are performed:
Time Frame: Validates that the date and time of the mandate is valid in relation to the current
debit payment
Debit Amount: Validates that the payment amount does not exceed the amount defined in the
mandate
2.2.2.2.1.6 SLA Credit Party
Ensures whether the payment is associated with a specific SLA Credit Party profile.
2.2.2.2.1.7 Rate Usage for Debit Side Conversion
If a currency conversion is required GPP invokes Rate Usage rules to determine the relevant foreign
currency exchange rate for each transaction.
Based on the type of conversion, the following types of Rate Usage Conversion rules may be invoked:
Base Amount Conversion: Determines the base amount foreign currency conversion rate for
transactions.
Debit Side Conversion: Determines the Debit-side foreign currency conversion rate for payments.
For more information, see GPP Currency Conversion Business Guide.
Mass Payments Processing
Global PAYplus Business Guide Page 41
2.2.2.2.2 Debit Side Workflow
2.2.2.2.2.1 Debit Party Processing
During the debit party processing, GPP identifies first in debit chain, loads the party and the debit
account.
For more information, see GPP Parties Identification Business Guide.
2.2.2.2.2.2 Party Detail Enrichment
GPP identifies and loads relevant account information for the first party in the chain - debit side of a
direct debit.
GPP invokes Debit Account Enrichment rules to determine the debit account number and usage
instructions for that account for Direct Debit. These rules enable a bank to define the relevant debit
account for a payment.
2.2.2.2.2.3 Creditor ID (CID) Validation (Incoming Flow)
The unique CID enables GPP to identify a creditor as part of the mass payment direct debit
functionality.
The CID also enables debtors and debtor Financial Institutions to do the following:
Check for a valid mandate
Identify a creditor to execute a debit refund
GPP invokes the CID Validation when a CID is input or accessed. For example, when a user creates
or updates a profile that contains a CID, such as a Creditor Account profile.
During CID validation, GPP searches for and selects the relevant Creditor ID Structure profile and
does the following:
Validates that the CID does not exceed the defined maximum length
Pre Processing - Debit Side Processing (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 7 of 34
Start
Debit Party
Processing
Repair
Dest MOP
STP
Validation
Submit
Cancel
Cont
Party Detail
Enrichment
Multi Office
– Re invoke
Destination
Party
Flow
Management
Creditor ID
Validation Mandate
Validation
Debit Mandate
validation
Mass Payments Processing
Global PAYplus Business Guide Page 42
Checks for optional discretionary data included in the CID
Derives the CID key, which is the CID without discretionary data
Validates the CID using the defined check digit algorithm
The CID Validation indicate if the CID is valid or invalid. When the CID is invalid, an error message is
generated.
The invoking process is responsible for handling the returned information correctly. For example:
If a GPP user types an invalid CID, the GUI displays an error message and prevents the user
from creating or updating the relevant profile.
If an incoming direct debit message contains an invalid CID, GPP stops processing the message
and automatically rejects it.
GPP validates that a CID is structured for the debit MOP in an outgoing direct debit message and
validates that the required relationships between a scheme, party, and CID exist in GPP, as defined in
the Creditor ID Structure and Creditor ID profiles.
GPP attempts to identify the Parameters profile using the relevant scheme, party, and CID key in the
following order of priority:
1. Scheme, party code, and CID
2. Scheme and party code
3. Party code only
4. Scheme only
If GPP cannot identify a matching Parameters profile, an error message is returned and GPP does
not continue to process the direct debit.
Upon identifying a matching Parameters profile, which defines the level of validation, GPP performs
one of the following:
No Validation: No additional validations are performed and the CID Processing service is
terminated.
Validate Creditor ID: GPP verifies that the CID is defined for the relevant party code, returns an
error message if the CID is not defined, and terminates the service.
Validate Creditor ID Account: GPP verifies that the CID is defined for the relevant creditor ID
account, returns an error message if the CID is not defined, and terminates the service.
Upon termination, the service returns one of the following:
A successful validation indicator
An unsuccessful validation indicator and an error message
2.2.2.2.2.4 Destination MOP Selection and MOP STP Validation
GPP uses Method of Payment (MOP) selection rules defined in GPP, to determine the best route for
the payment to be delivered, for example, via clearing, SWIFT. The MOP parameters are also used to
determine whether the transaction continues processing as a single message or should be sent out in
a file.
For more information, see GPP Method of Payment Business Guide.
Mass Payments Processing
Global PAYplus Business Guide Page 43
2.2.2.2.2.5 Mandate Validation and Enrichment
GPP invokes Mandate Validation rules to validate the mandate-related attributes.
GPP Mandate Validation: Validates that the creditor party of an incoming direct debit is authorized
to collect a payment from a debtor party. GPP validates the mandate using reference data defined
in Mandate profiles and Mandate Validation rules. GPP implements the validation at the following
times:
o Time of Receipt: Upon receipt of an incoming direct debit message
o Processing Day: On the specific processing day of a direct debit
Upon receipt of an incoming direct debit, the GPP does the following:
o Verifies that a valid mandate exists between the creditor and debtor. The UMR (Unique
Mandate Reference) and CID (Creditor ID) of the incoming direct debit is used to search for
and match a direct debit to a mandate.
o Evaluates Mandate Validation business rules to check that the incoming direct debit meets
the requirements of the mandate. The business rules might implement an Override STP
profile to generate error messages and message mapping. The Mandate Validation rules can
be attached to a MOP or to the local office.
o Creates a mandate if a valid mandate does not exist and the incoming direct debit contains
the required information.
o Updates an existing mandate with information contained in an incoming direct debit if the
incoming direct debit contains specific mandate amendment information.
Mandate Enrichment: Enriches mandatory fields in an outgoing direct debit that GPP generates
and sends to a Clearing. After receiving a direct debit (such as a pain.008 message) from an
initiating creditor party, GPP implements the Mandate Enrichment process if the following are
true:
o The direct debit is missing mandatory information
o A valid mandate has been identified for the direct debit
GPP extracts the missing information from the mandate and inserts it into the direct debit, which
GPP sends to a Clearing. GPP uses the mandate to enrich the outgoing direct debit with the
following information:
o UMR: Unique mandate identification code supplied by a creditor. GPP generates this unique
key for every mandate that is created.
o CID: Unique creditor identification code supplied by a creditor bank .
o Signing Date: Date that the debtor customer signed or authorized the creditor to debit the
debtor customer’s account.
GPP validates the mandate:
If the mandate is not valid the payment is moved to the Rejected Queue, as defined in the
Override STP profile for the specific Mandate Validation rule. The Override STP profile must have
a Mandate Validation type.
If the mandate is valid (attributes match the defined rule conditions), GPP routes the direct debit
message to the queue as defined in the relevant Override STP profile and stops evaluating
additional Mandate Validation rules.
2.2.2.2.2.6 Multi Office - Re Invoke Destination Party
In a multi office scenario where the debtor is located in a different office than the creditor, the debit
side is re-processed and re-evaluates all the rules on the destination office.
Mass Payments Processing
Global PAYplus Business Guide Page 44
2.2.2.3 Post MOP
2.2.2.3.1 Post MOP Workflow
2.2.2.3.2 Debit Transaction Code
In this process GPP selects a debit code per transaction. This code can be exposed for external
systems in a structured way. Examples of the code are type of transaction, type of customer, and
fees.
2.2.2.3.3 Credit Transaction Code
In this process GPP selects a credit code per transaction. This code can be exposed for external
systems in a structured way. Examples of the code are type of transaction, type of customer, and
fees.
2.2.2.3.4 Prevent STP
GPP uses Override STP profiles to prevent Straight-Through Processing (STP) of specific payments.
The Override STP profile can be defined for the following:
Special Instruction: Prevent STP processing of a payment with specific characteristics, such as a
settlement amount greater than a defined value.
Validation: Prevent STP processing of a payment that is invalid as defined by the specific
conditions, such as a missing product code.
For a list of error statuses, see Appendix B: STP Validation Error Statuses.
For more information, see GPP Special Instructions Business Guide.
Pre Processing - Post MOP (I)
External
Systems
IntegrationManual Handling
Global PayPlus Services
Platform
Page 8 of 35
Compliance
Validation
Cont
Debit
Transaction
code
Credit
Transaction
code Prevent STP Generate Sub
Batch
Wait Sub-
Batch
Wait
Sched Sub
Batch
Processing
date
Cancel
Start
Accumulate transaction
according to grouping ID
Batch compliance request
Compliance
request - file
buffer
Fees
(itemized)
Batch Booking=’False’
Flow
Management
Future
Date
Mass Payments Processing
Global PAYplus Business Guide Page 45
2.2.2.3.5 Fees (Itemized)
The relevant fees are determined for each party in the transaction. This is performed when posting is
required on the transaction level (Batch Booking is false).
For more information, see GPP Fees - Core Processing Business Guide
2.2.2.3.6 Compliance Validation
GPP invokes Compliance Validation rules to determine whether to send a specific payment for
compliance to verify that a payment complies with various anti-money laundering regulations.
GPP enables the following types of Compliance Validation rules:
Submit: If a payment meets the conditions defined in the rule, GPP sends the transaction for
compliance verification.
Bypass: If a payment does not meet the conditions defined in the rule, GPP does not send the
transaction for compliance verification.
2.2.2.3.7 Generate Grouped Transaction (Sub Batch)
As part of this processing GPP groups number of payments which have similar parameters in order to
allow single posting on the account or perform single currency conversion for the entire S message.
When GPP completes preprocessing for all individual transactions, additional file validations are
invoked as follows:
Number of Transactions: Validates that the total number of transactions counted in an incoming
file matches the declared number of transactions in the file.
Control Sum: Validates that the total amount of all transactions contained in the incoming file is
equal to the amount defined in the file header. GPP includes all payment amounts when checking
the control sum, regardless of the defined currency for an individual transaction.
Rejected Transactions: Validates that the total number of transactions (expressed as a
percentage) in an incoming file that are rejected by GPP does not exceed a threshold set by the
bank.
Transactions that successfully complete these file validations continue to be processed in the Sub-
Batch Generation.
If the additional validations are not successful, GPP stops processing the transactions, and might hold
the file for manual handling or reject it.
2.2.3 Payment Grouping (Sub Batch) Generation
Sub-Batch generation accumulates transactions that are sent out in files and completes processing
on individual transactions.
GPP collects and group transactions originated in a file into groups based on definable criteria in
order to apply actions on the entire group for example, posting, fees, and foreign exchange.
Mass Payments Processing
Global PAYplus Business Guide Page 46
2.2.3.1 Sub Batch Generation (S) Workflow
2.2.3.2 Rate Usage for Debit Side Conversion
GPP uses Rate Usage rules to determine the relevant foreign currency exchange rate for each
transaction, if a currency conversion is required.
Mass Payments Processing
Global PAYplus Business Guide Page 47
The Debit Side Conversion determines the debit-side foreign currency conversion rate for
transactions.
2.2.3.3 Value Date
GPP recalculates the Value Date for the S message.
For more information, see Value Date and Cutoff Business Guide.
2.2.3.4 Debit Transaction Code
In this process GPP selects a debit code per transaction. This code can be exposed for external
systems in a structured way. Examples of the code are type of transaction, type of customer, fees.
2.2.3.5 Credit Transaction Code
In this process GPP selects a credit code per transaction. This code can be exposed for external
systems in a structured way. Examples of the code are type of transaction, type of customer, fees.
2.2.3.6 Fees (Sub Batch)
The relevant fees are determined for each party in the S message. This is performed if posting is
done on the S message (Batch Booking flag is true).
For more information, see Fees – Core Processing Business Guide.
2.2.3.7 Debit Hold Until Time
GPP provides a mechanism of stopping S message processing up until a pre-defined time. This is
performed using the Hold Until Time rule. When a rule is selected to a sub batch, based on specific
attribute, the sub batch is held until a pre-defined time (and as a result, all of the transactions related
to the Sub batch are held until its completion). On the selected time, Sub batch is released back to
processing.
2.2.3.8 Interface Selection
GPP uses Interface Selection rules to interact with external interfaces at specific stages during the
payment processing. At this stage the Balance Inquiry Interface can be selected.
If GPP determines that a payment matches the defined rule conditions, the defined action of the rule
is executed, which can be one of the following:
Bulk Interface Request: Message attributes are accumulated and stored, which GPP later uses
to generate a bulk request to an external interface.
Individual Interface Request: Individual message attributes are stored and GPP generates a
single request to an external interface.
The action for an Interface Selection rule implements an Interface profile that includes definitions for
interface requests and responses such as:
Protocol: The protocol used by GPP to communicate with the external interface.
Format Type: The format of the incoming response or outgoing request.
Connection Point: The location of the request that is sent or of the response that is received.
2.2.3.9 Stop Flag
Account stop flag check is performed on the S message account. The stop flag is either received from
the Balance Inquiry response or setup in the account profile.
Mass Payments Processing
Global PAYplus Business Guide Page 48
2.2.3.10 Compliance Check
A GPP Compliance service ensures compliance with various anti-money laundering regulations and
foreign asset controls. GPP verifies that all incoming and outgoing payments in the S message
comply with the latest regulations, such as embargoes and anti-terrorist financing regulations.
GPP performs the compliance check in a two-step process:
5. Initial Response: GPP sends an initial request to the compliance interface, for all transactions in
the bulk as a single request. The interface returns one of the following types of Initial Responses:
o No Hit: The interface determines that the payment complies with all relevant regulations. GPP
continues processing the payment.
o Possible Hit: The interface determines that the payment might not comply with all relevant
regulations. GPP does not continue processing the payment. It is pending receipt of a Final
Response.
6. Final Response: The interface returns one of the following types of Final Responses:
o Passed: The interface determines that the payment complies with all relevant regulations.
GPP continues processing the payment.
o Rejected: The interface determines that the payment does not comply with all relevant
regulations and returns a rejected indicator. GPP rejects the payment by setting the payment
status to Rejected and routing the message to the Rejected queue. GPP does not continue
processing the message.
o Seized: The interface determines that the payment does not comply with all relevant
regulations and returns a seized indicator. GPP implements a process to seize the payment
by setting the payment status to Seized and routing the message to the Seized queue. This is
a final status and GPP does not continue processing the message.
2.2.3.11 External FX (Lump Sum)
GPP Performs currency conversion for the lump sum amount when the payment currency is different
to the account currency. .
GPP calculate conversions using an FX rate obtained from GPP or using a rate from an external
system.
2.2.3.12 Posting Consolidation (Credit Side)
GPP triggers the relevant interface to perform required posting.
In a direct debit, credits the creditor or clearing participant and debits the relevant suspense account.
2.2.3.13 Flow Management
As part of the flow management the S message is routed to Complete after posting and GPP
continues the execution processing on the individual transactions.
2.2.4 Execution
GPP generates posting and processes the outgoing file during the execution stage. GPP performs a
few generic steps and then based on bulking profile existence, GPP process individual executions
and bulk executions.
Mass Payments Processing
Global PAYplus Business Guide Page 49
2.2.4.1 Execution Workflow
2.2.4.2 Hold Until Time
GPP provides a mechanism of stopping selected transaction processing up until a pre-defined time.
This is performed using the Timed Hold rule. When a rule is selected to a sub batch, based on
specific attribute, the sub batch is held until a pre-defined time (and as a result, all of the transactions
related to the Sub batch are held until its completion). On the selected time, Sub batch is released
back to processing.
2.2.4.3 Interface Selection (Balance Inquiry)
GPP usage the interface selection rules to generate an external balance inquiry request. For Balance
Inquiry standard interface information, see GPP Technical Guide Balance Inquiry Interface.
2.2.4.4 Stop Flag
Account stop flag check is performed on the individual account. The stop flag is either received from
Balance Inquiry response or setup in the account profile.
2.2.4.5 Compliance Check
GPP performs a compliance request on the individual payment.
2.2.4.6 External FX (Individual)
GPP generates an external FX request for individual payments, when posting indicator refers to
individual payments.
2.2.4.7 Posting Itemized (Credit Side)
GPP triggers the relevant interface to perform required posting. For example for CTO GPP perform
the debit posting per transaction.
Mass Payments Processing
Global PAYplus Business Guide Page 50
For more information, see Mass Payments Accounting
2.2.5 Execute Individual
During this process, GPP process individual executions.
2.2.5.1 Execute Individual Files Workflow
2.2.5.2 Liquidity
In this step, GPP checks the liquidity status for clearing the settlement account.
For more information, see GPP Liquidity & Risk Management Business Guide
2.2.5.3 Posting (Individual Debit)
GPP triggers the relevant interface to perform the required posting.
For more information, see Mass Payments Accounting
2.2.5.4 Format Out and Transmission
GPP generates the out payment.
2.2.5.5 Match Response to Payment
GPP matches the response to the individual payment
2.2.5.6 Response
2.2.5.6.1 DDO Negative Response
Upon receipt of a negative response, the DDO is routed to the Reject queue.
Mass Payments Processing
Global PAYplus Business Guide Page 51
2.2.5.6.2 DDO Positive Response
Upon receipt of a positive response, the DDO remains in the Complete queue.
2.2.6 Execute Bulk Destination
GPP collects and organizes transactions destined for a file-based clearing system into bulks based on
definable criteria. An outgoing file can contain multiple message types. For example, a single
outgoing file can contain direct debits, recall requests, and recall returns. An outgoing file can also
contain transactions that were received individually and transactions that were received in files.
GPP uses the specific bulking parameters for each Method of Payment (MOP) that handles
transaction bulking. These parameters are defined in the Bulking profile that is associated with the
MOP.
2.2.6.1 Execute Bulk Workflow
2.2.6.2 Out Bulk Grouping ID Selection
GPP invokes Out Bulk Grouping ID Selection rules to determine the Group ID - Out data manipulation
rule that GPP uses to build the OFID, and OGID.
The OFID (outgoing file ID) is used to place transactions into the relevant outgoing file.
The OGID (outgoing group ID) is used to place transactions with common attributes into relevant
groups in the outgoing file.
When generating an outgoing customer file (pain.001 and pain.008), GPP determines:
7. The relevant file into which the transaction should be placed using the OFID. The OFID
determines, for example, if a file must only contain transactions of a single message type or value
date.
8. The relevant Group Header within the outgoing file into which the transaction should be placed
using the OGID.
Mass Payments Processing
Global PAYplus Business Guide Page 52
2.2.6.3 Bulking Sending Time
GPP invokes Bulking Sending Time rules to determine the appropriate time to generate and send
outgoing files of payment messages. Each sending time defined in the Bulking profile must have a
corresponding Bulking Sending Time rule.
This rule also enables authorized GPP users to define a last sending time for a specific message
type.
Bulking profile can be configured to send out the relevant transaction upon incoming file processing.
In this case, Bulking sending time rules are not evaluated and Out file generation is triggered once
incoming file processing is completed (i.e. all transactions received in the incoming file are
processed).
2.2.6.4 Posting (Individual Debit Side)
GPP triggers the relevant interface to perform required posting.
For more information, see Mass Payments Accounting
2.2.6.5 Flow Management
GPP routes all individual transactions to the Complete queue and creates the A message for file
generation.
2.2.6.6 Out File Generation
GPP invokes Bulking Sending Time rules to determine the time to generate and send outgoing files of
payments. Each sending time defined in the Bulking profile must have a corresponding Bulking
Sending Time rule.
This rule also enables authorized GPP users to define a last sending time for a specific message
type.
For more information about Bulking profiles and sending times, see Bulking Profile.
GPP also enables authorized users to generate outgoing files containing groups of transactions that
have successfully completed processing and send them to a CSM, regardless of the defined sending
time. For more information, see Pending Outgoing File.
2.2.6.7 Posting (Consolidated Debit)
GPP triggers the relevant interface to perform required posting.
For more information, see Mass Payments Accounting
2.2.6.8 Match Response to Payment
GPP matches the response to the file level.
2.2.6.9 Response Handling
2.2.6.9.1 DDO Negative Response
Upon receipt of a negative response, the DDO are routed to the Reject queue.
2.2.6.9.2 DDO Positive Response
Upon receipt of a positive response, the DDO remains in the Complete queue.
Mass Payments Processing
Global PAYplus Business Guide Page 53
2.2.7 Acknowledgment Reporting
GPP can generate file status reports for FI customers that enable the customers to track file and
transaction processing. GPP can generate these reports at different stages of the processing
workflow.
It is the same process for Credit Transfer and Direct Debit. For more information, see
Acknowledgment Reporting.
2.2.8 Compensation Calculation
The GPP Compensation functionality calculates the amount of compensation due on a direct debit
refund. In this process GPP uses defined Interest Rates and Interest Types profiles, as determined by
the relevant MOP, to calculate the number of days of interest and amount of interest to add to the
amount of the original payment.
GPP does following:
Calculates the number of relevant calendar days.
Calculates the amount of compensation due on a direct debit refund.
After performing the required calculations, GPP invokes STP Validation rules to determine if the
compensation amount meets minimum and maximum amounts defined by the bank.
2.2.8.1 Number of Days Calculation
GPP calculates the number of calendar days for each month between the original settlement date and
the refund message date. GPP uses these days, for each specific month, to calculate the amount of
interest due on a direct debit refunded.
GPP calculates the number of calendar days using one of the following methods, as defined in the
relevant Interest Types profile:
30 360: Calculations use a 30-day month and 360-day year.
Actual 360: Calculations use the actual number of days in each month and a 360-day year.
Actual 365: Calculations use the actual number of days in each month and a 365-day year.
In each method, GPP does not count the refund message day in the calculation.
2.2.8.2 Number of Days Calculation Comparison
Authorized GPP users can define different methods to calculate the number of calendar days to use
when calculating the amount of compensation due on a direct debit refund.
2.2.8.3 Compensation Calculation
Compensation calculation is performed in conjunction with the following variables:
Interest Rate: The interest rate for each month as defined in the Interest Rates profile (see
Interest Rates Profile). GPP calculates the amount of interest for each month by multiplying the
Days in Month to Days in Year Ratio by the Interest Rate for the specific month.
Number of Calendar Days: The number of calendar days for each month between the original
settlement date and the refund message date.
Number of Days in Year: The number of days in a year as defined in the Method field of the
Interest Types profile (see Interest Rates Profile). GPP divides the Number of Days by the month
to the Number of Days in Year to calculate the Days in Month to Days in Year Ratio.
Mass Payments Processing
Global PAYplus Business Guide Page 54
Settlement Amount: GPP adds the total amount of interest from all months to the Original
Settlement amount to calculate the full Compensation Amount.
GPP uses definitions from the relevant Interest Types and Interest Rates profiles to determine the
values of the variables. The amount of compensation calculated by GPP depends on the value of
each variable.
For example, the following table shows the compensation amounts for each method type for a sample
refund message generated on June 30, 2013. The sample message is a 500 euro direct debit with an
original settlement date of April 5, 2013.
Method
Calculated
Compensation
Amount
Calculation
Actual 360 Method
508.45
See Example: Actual 360 Compensation
Calculation
Actual 365 Method
508.33
See
Example: Actual 365 Compensation Calculation
30 360 Method
508.36
See Example: 30 360 Compensation Calculation
All calculations use the following interest rates:
April 2013: 0.05%
May 2013: 0.07%
June 2013: 0.09%
2.2.8.3.1 Example: Actual 360 Compensation Calculation
The following table shows the Actual 360 calculations for a sample direct debit refund message.
Month
Number
of Days
Calculation
Interest
Amount
April 2013
26
((26/360)*0.05)*500
1.81
May 2013
31
((31/360)*0.07)*500
3.01
June 2013
29
((29/360)*0.09)*500
3.63
Total
86
8.45
Total Compensation
508.45
2.2.8.3.2 Example: Actual 365 Compensation Calculation
The following table shows the Actual 365 calculations for a sample direct debit refund message.
Month
Number
of Days
Calculation
Interest
Amount
April 2013
26
((26/365)*0.05)*500
1.78
May 2013
31
((31/365)*0.07)*500
2.97
June 2013
29
((29/365)*0.09)*500
3.58
Total
86
8.33
Total Compensation
508.33
Mass Payments Processing
Global PAYplus Business Guide Page 55
2.2.8.3.3 Example: 30 360 Compensation Calculation
The following table shows the 30 360 calculations for a sample direct debit refund message.
Month
Number
of Days
Calculation
Interest
Amount
April 2013
26
((26/360)*0.05)*500
1.81
May 2013
30
((30/360)*0.07)*500
2.92
June 2013
29
((29/360)*0.09)*500
3.63
Total
85
8.36
Total Compensation
508.36
2.2.9 Mandate Management, Validation & Enrichment
2.2.9.1 Direct Debit Mandate Management
A mandate is an agreement between a debtor and creditor that authorizes a creditor to collect a
payment from a debtor. A mandate also authorizes a debtor’s bank to pay a direct debit (collection).
GPP supports the following types of mandates:
Manually-Created: A mandate created by an authorized GPP user. A user can create a mandate
via the GPP user interface using information received from a creditor or debtor.
Live: A mandate created or amended by GPP using information from an incoming direct debit
message. A manually-created mandate becomes a live mandate upon receipt of a direct debit
that contains amendment information, which causes GPP to update the mandate.
The GPP user interface enables authorized users to create and manage mandates. GPP identifies
each mandate using the following unique identifiers:
Unique Mandate Reference (UMR): Unique mandate identification code supplied by a creditor.
GPP uses this field and the Creditor ID field to identify a mandate.
Creditor ID (CID): Unique creditor identification code supplied by a creditor bank. GPP uses this
field and the UMR field to identify a mandate. For more information, see Creditor ID (CID)
Validation (Incoming Flow)
GPP enables authorized users to create mandates using Mandate profiles to define the relationship
between a creditor and a debtor. This information, such as the UMR and CID, is supplied by the FI.
GPP uses these two fields to search for and validate mandates upon receipt of incoming direct debit
messages.
Authorized users can define additional mandate validations. These include:
Maximum debit amounts for a single transaction
Maximum aggregate amount
Maximum number of debits for a mandate
Each incoming direct debit message must include the type of direct debit. Upon receipt of a direct
debit, the GPP Mandate Validation process checks for an existing mandate and does one of the
following as per the type of debit:
Mass Payments Processing
Global PAYplus Business Guide Page 56
Initial and One-Off Debits:
o If a valid mandate does not exist, GPP automatically creates one with information contained
in the incoming debit message and continues message processing. For a Back to Back (B2B)
scheme type, a mandate must be defined before a collection arrives.
o If a valid mandate exists, GPP continues message processing and might update the mandate
if the incoming debit message contains amendment information.
Recurring and Final Debits:
o If a valid mandate does not exist, GPP rejects the incoming debit message.
o If a valid mandate exists, GPP continues message processing and might update the mandate
if the incoming debit message contains amendment information.
2.2.9.2 Mandate Validation
The Mandate Validation processing enables GPP to validate that the creditor party of an incoming
direct debit has authorization to collect a payment from a debtor party, as part of GPP mass payment
direct debit functionality. GPP implements the service using reference data defined in Mandate
profiles and Mandate Validation rules.
GPP implements this processing at the following times:
Time of Receipt: Upon receipt of an incoming direct debit message
Processing Day: On the specific processing day of a direct debit
Upon receipt of an incoming direct debit, GPP does the following:
Verifies that a valid mandate exists between the creditor and debtor. GPP uses the message
UMR and CID of the incoming direct debit to search for and match a direct debit to a mandate.
GPP can track and handle updates to an incoming UMR and CID as follows:
o If a UMR has changed, GPP searches for a valid mandate using the original UMR. GPP
tracks UMR changes in the audit trail.
o If a CID has changed, GPP invokes the CID Validation to determine the relevant CID key.
GPP tracks CID changes in the audit trail.
Evaluates Mandate Validation business rules to check that the incoming direct debit meets the
requirements of the mandate. The business rules might implement an Override STP profile to
generate error messages.
Creates a mandate if a valid mandate does not exist and the incoming direct debit contains the
required information.
Updates an existing mandate with information contained in an incoming direct debit if the
incoming direct debit contains specific mandate amendment information.
After GPP verifies that a mandate exists between the relevant parties, GPP can then perform the
following validations:
Time Frame: Validates that the date and time of the mandate is valid in relation to the current
debit payment
Debit Amount: Validates that the transaction amount does not exceed the amount defined in the
mandate
2.2.9.3 Mandate Enrichment
The Mandate Enrichment process enables GPP to provide mandatory fields in an outgoing direct
debit that GPP generates and sends to a CSM.
Mass Payments Processing
Global PAYplus Business Guide Page 57
After receiving a direct debit (such as a pain.008 message) from an initiating creditor party, GPP
implements the Mandate Enrichment process if the following are true:
The direct debit is missing mandatory information.
GPP has identified a valid mandate for the direct debit.
When GPP in the creditor bank generates an outgoing direct debit (such as a pacs.003 message),
GPP identifies that mandatory information is missing. GPP extracts the missing information from the
mandate and inserts it into the direct debit, which GPP sends to a CSM.
GPP implements the Mandate Enrichment process only after it identifies a valid mandate for a direct
debit. The mandate enriches the outgoing direct debit with the following information:
UMR: Unique mandate identification code supplied by a creditor
CID: Unique creditor identification code supplied by a creditor bank
Signing Date: Date that the debtor customer signed or authorized the creditor to debit the debtor
customer’s account
Mass Payments Manual Handling
Global PAYplus Business Guide Page 58
3 Manual Handling
3.1 Manual Repair
GPP mass payment functionality has the ability to process files of transactions with a minimal need
for manual intervention, which reduces processing overhead and increases STP rates. In rare cases
where a payment cannot be automatically processed, GPP rejects or returns the problematic
message and continues processing the remaining messages in the mass payment file.
In specific instances, GPP also enables FIs to route problematic individual payments to a queue for
manual handling. Depending on the type of manual repair, GPP performs the required account
posting, as described in Mass Payments Accounting.
During the Preprocessing flow, GPP can be configured to route payments with the following
conditions to a queue for manual handling:
Possible duplicate messages
Invalid credit or debit party
Invalid credit or debit account
MOP selection failure
Mandate validation failure
Value date determination failure
Authorized GPP users can manually repair payments in one of the following ways:
Cancel: A user can cancel a payment in only very specific instances. GPP invokes business rules
on each such payment that can require a second or third approval before routing the payment to a
cancellation workflow for processing.
Submit: A user manually repairs a payment as required. GPP invokes business rules on each
such payment that can require a second or third approval before routing the payment to an
individual payment workflow for processing.
3.2 Manual Repair Accounting
The type of accounting configured for GPP determines how it handles repaired payments. GPP uses
one of the following accounting types:
Gross: Using this accounting method, GPP includes all relevant payments in the (S) message
and generates a reverse posting, individual (I) message for each transaction that is manually
rejected or canceled.
Net: Using this accounting method, GPP includes in the S message only those transactions that
complete preprocessing. GPP generates an I message for each transaction that is manually
rejected, or canceled.
3.3 Manual Cancellation
Note: In GPP dual control is configured. That means that, an authorized user must approve the
cancellation action before GPP initiates the cancellation process.
3.3.1 Incoming File Cancellation
The File Summary Detail - Incoming page in GPP enables authorized users to view and initiate
actions on an incoming mass payment file. One of the actions can be to cancel an incoming file.
Mass Payments Manual Handling
Global PAYplus Business Guide Page 59
To cancel a file, a user accesses the relevant incoming file via the File Summary Detail - Incoming
page and selects Canceled from the Send File To dropdown list. Upon clicking Save, GPP initiates
the file cancellation process.
A user can cancel an incoming file only if all the following conditions apply:
The user has write permission for the File Summary Detail page.
The file is an incoming file received directly from an originator. A file received from an ACH cannot
be cancelled.
The file does not contain reject, return, or Notification of Changes (NOC) messages.
The file is not pending a previous cancellation action.
The file has one of the following statuses:
o Completed
o Duplicate
o Hold
o NotValidCtrlSum
o NotValidInitgPty
o NotValidNbOfTxs
o StopPreprocessing
Upon completion of the cancellation process, GPP does the following:
Generates a relevant Audit Trail entry for the file
Generates a relevant Audit Trail entry for every batch in the file
Generates a relevant Audit Trail entry for every transaction in the file
Updates the file status to Cancelled
Updates the status of every batch of transactions in the file to BatchCanceled
Updates the status of every transaction in the file to Cancelled or Reversed, depending on the
MOP and whether the payment is released to an ACH
Generates reverse posting for every transaction, as required
For more information about the File Summary Detail page, see File Summary.
3.3.2 Incoming Batch Cancellation
The Batch Summary Detail page in the GPP GUI enables authorized users to view and initiate actions
on a specific batch of transactions in an incoming mass payment file. One of the actions is to cancel a
specific batch of transactions.
To cancel a batch, a user accesses the relevant batch of transactions via the Batch Summary Detail
page and selects BatchCanceled from the Send Batch To dropdown list. Upon clicking Save, GPP
initiates the batch cancellation process.
A user can cancel an incoming batch of transactions only if all the following conditions are true:
The user has write permission for the Batch Summary Detail page.
The batch is in an incoming file received directly from an originator. A batch in a file received from
an ACH cannot be cancelled.
The batch does not contain reject, return, or Notification of Changes (NOC) messages.
Mass Payments Manual Handling
Global PAYplus Business Guide Page 60
Neither the batch nor the file that contains the batch is pending a previous cancellation action.
The file that contains the batch is not pending an approval of cancellation action.
The batch has one of the following statuses:
o BatchCompleted
o BatchHold
o Duplicate
o Skip
Upon completion of the cancellation process, GPP does the following:
Generates a relevant Audit Trail entry for the batch
Generates a relevant Audit Trail entry for every transaction in the batch
Updates the status of the batch to BatchCanceled
Updates the status of every transaction in the batch to Cancelled or Reversed, depending on the
MOP and whether the payment is released to an ACH
Generates reverse posting for every transaction in the batch, as required
For more information about the Batch Summary Detail page, see Batch Summary.
3.3.3 Incoming Transaction Cancellation and Reversal
The Transaction Data page in the GPP GUI enables authorized users to view and initiate actions on a
specific transaction in an incoming file. One of the actions is to cancel or reverse a transaction.
A user can access the relevant transaction via the Transaction Data page to do one of the following:
Cancel a Transaction: A user can initiate a cancellation on a transaction before it is released to
an ACH.
Reverse a Transaction: A user can initiate a reversal on a transaction after it is released to an
ACH or if the status is Completed.
Note: If a transaction is designated with a BOOK MOP, a user can cancel the transaction before
payment posting or reverse the transaction after payment posting.
A user can cancel or reverse a transaction only if all the following conditions are true:
The transaction does not have one of the following statuses:
o Approve_Cancel
o Cancelled
o Released
o Returned
o Reversed
o Rejected
o Verify
The transaction is in an incoming file received directly from an originator. A transaction in a file
received from an ACH cannot be cancelled or reversed.
Neither the batch that contains the transaction nor the file that contains the transaction is pending
a previous cancellation action.
Mass Payments Manual Handling
Global PAYplus Business Guide Page 61
Neither the batch that contains the transaction nor the file that contains the transaction is pending
a previous approval of cancellation action.
The transaction is a monetary transaction. For example, an NOC cannot be canceled or reversed.
Upon completion of the cancellation or reversal process, GPP does the following:
Generates a relevant Audit Trail entry for the transaction
Updates the status of the original payment to Cancelled or Reversed
Generates reverse posting for the transaction, as required
Generates an outgoing payment reversal message and links it to the original payment, as
required
3.4 GPP Mass Payments User Interface
The GPP User Interface mentioned in this section enables access to mass payment functionality.
Note: For a detailed description of all the fields, see GPP Online Help.
3.4.1 File Summary
3.4.1.1 File Summary Page: Incoming Files
The Incoming File Summary page provides information about incoming files. It includes the following
information and access areas:
General File Information: Displays general information about the selected file, for example,
internal file ID, file name, location, status (Completed, Duplicate), and file direction.
Incoming File Information: Displays additional information about the selected incoming file, such
as file reference, initiating party, file creation date, and file priority. It also includes indicator that
enables an authorized user to send the file for continued processing. The available options for
continued processing are dependent on the current status of the file. For example, a file that
currently has a Hold status can be canceled by selecting Canceled from the available options in
this field.
Action Buttons: Provides access to specific types of information about the selected file.
3.4.1.2 File Summary Page: Outgoing Files
The Outgoing File Summary page provides information about individual outgoing mass payment files.
It includes the following information and access areas:
General File Information: Displays general information about the selected mass payment file for
example, Internal File ID, File Name, location, status (for example, ReadyToBeSent) and file
direction.
Outgoing File Information: Displays additional information about the selected outgoing mass
payment file, such as file type, number of payments, MOP, associated bulking profile, and
sending/receiving institutions. It also indicates whether a validation file is expected for the
outgoing file.
Action Buttons: Provides access to specific types of information about the selected mass payment
file.
Mass Payments Manual Handling
Global PAYplus Business Guide Page 62
3.4.1.3 File Summary Action Buttons
The following table provides details of the action buttons in the Incoming and Outgoing File Summary
pages.
Button Name
Incoming/
Outgoing
Description
View Sub Batch
Incoming
Displays information about an incoming file grouped by UGID, in
the Sub Batch page. It includes information related to the Sub
Batch such as Unique grouping ID, MID of the S message, Debit
Account/Total Debit Amount of the S message, Debit/Credit
Currency of the S message, Total Message Count, MID of the
individual message included in the Sub Batch.
View Batch
Summary
Incoming
Displays information about batches in the selected file.
Outward Recall
Incoming
Enables access to recall mass payments files matched to the
selected file.
Message Errors
Incoming
Displays message errors generated for the selected file.
Audit Trails
Incoming
Displays the audit trail of the selected file.
Rule Logs
Incoming
Displays the business rules invoked on the selected file.
View
Compliance
Files
Incoming
Displays information about each request sent to the compliance
interface for payments in the selected file.
View Out Buffer
Outgoing
Displays information about the chunks of messages in the
selected file.
Bulking Profile
Outgoing
Enables access to the Bulking profile attached to the outgoing
file.
3.4.2 Batch Summary
The GPP Batch Summary page enables authorized users to view information about all batches
contained in a specific incoming mass payment file. The information is presented in the form of a grid.
When clicking on a record in the grid the Batch Summary Detail page is opened, which enables
authorized users to view information about a specific batch of payments from an incoming mass
payment file. The available information is internal file ID, batch ID, number of transactions in the
batch, number of rejects in the batch, and batch status.
The following table provides details of the action buttons in the Incoming Batch Summary pages.
Button Name
Description
Message Errors
Displays message errors generated for the selected batch
Audit Trails
Displays the audit trail of the selected batch
Rule Logs
Displays the business rules invoked on the selected batch
Mass Payments Manual Handling
Global PAYplus Business Guide Page 63
3.4.3 Pending Outgoing Files Summary
The Pending Outgoing Files Summary page displays a record for each group of transactions that
have successfully completed processing and are available for inclusion in an outgoing file, which GPP
sends to a CSM in a defined structure and at a defined sending time.
GPP groups each record by MOP, Bulking profile, and sending time. For more information, see
Bulking Profile.
3.4.4 Pending Outgoing File
The Pending Outgoing File page displays information about an individual group of transactions that
have successfully completed processing and are available for inclusion in an outgoing file, which GPP
sends to a CSM in a defined structure and at a defined sending time. For more information, see
Bulking Profile.
GPP groups each record by MOP, Bulking profile, and sending time.
The File Action field generates outgoing files containing groups of transactions and sends them to a
CSM, regardless of the defined sending time.
An authorized user can select one of the following actions:
Send Immediately Only This Window: GPP generates outgoing files for all records displayed in
the Pending Outgoing Files Summary page that have a sending time identical to the sending time
of the selected record, and then sends each file to the relevant CSM.
Send Immediately All Up To This Window: GPP generates outgoing files for all records displayed
in the Pending Outgoing Files Summary page that have a sending time that is identical to or prior
to the sending time of the selected record, and then sends each file to the relevant CSM.
Send All: GPP generates outgoing files for all records displayed in the Pending Outgoing Files
Summary page, and then sends each file to the relevant CSM.
The Pending Outgoing Files Summary page enables access to this page.
3.4.5 Transaction Data
The Transaction Data page provides all detailed data that is associated with a transaction.
Mass Payments Business Setup
Global PAYplus Business Guide Page 64
4 Business Setup
4.1 Profiles
These are the details of the required setup in GPP profiles for Mass Payments.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
4.1.1 Accounts Profile
GPP Accounts profile holds information about accounts maintained in GPP. To implement mass
payment functionality, the Accounts profile includes Account Scheme Usage field which allows an
authorized user to designate an account as one of the following:
Both: The account is used for both credit transfers and direct debits
Credit Transfer: The account is used for credit transfers only
Direct Debit: The account is used for direct debits only
4.1.2 Batch Control Profile
The GPP Batch Control profile defines processing preferences for each batch in an incoming mass
payment file. This enables a Financial Institution to control the processing workflow for individual
transactions contained in a specific batch.
These processing preferences can be defined:
Set a dedicated duplicate check profile for a batch
Select an alternative MOP for when the ACH is not applicable
Control whether or not the Value date can be rolled forward when it is a Weekend/Holiday
Control whether or not an individual transaction within a batch can be repaired
Authorized GPP users can view information about batches in incoming mass payment files. For more
information, see Batch Summary.
4.1.3 Bulking Profile
The Bulking profile defines bulking attributes for outgoing mass payment files. A Bulking profile can be
associated with a specific MOP or with a specific receiving party.
GPP users can associate a Bulking profile with a MOP using the Bulking Profile field in the Method of
Payment profile. GPP uses this field to determine the appropriate Bulking profile as follows:
If the field contains a value, GPP invokes Parties Bulking Profile Selection rules during
Preprocessing to determine if a Bulking profile is defined to override the default Bulking profile
that is defined in the Method of Payment profile. The Parties Bulking Profile Selection rules
enable a Financial Institution to define multiple Bulking profiles for a single MOP type.
If the field is blank, GPP does not access a Bulking profile for the specific MOP. For example,
BOOK MOP transactions, which are not transmitted to an external ACH or bank, do not require a
Bulking profile.
The Bulking profile defines:
Line delimiter used by GPP when generating an outgoing file
Destination folder
Mass Payments Business Setup
Global PAYplus Business Guide Page 65
Minimum number of transactions that GPP includes in a single outgoing file for a specific Bulking
profile
Maximum number of transactions that GPP includes in a single bulk for a specific Bulking profile
Maximum number of bulks of transactions that GPP includes in a single outgoing file
Maximum number of files in a single day that GPP generates for a specific Bulking profile
Maximum transaction amount of all transactions in a single bulk
4.1.4 Direct Debits
GPP uses the profiles mentioned in this section to enable direct debit functionality.
4.1.4.1 Creditor ID Structure Profile
The Creditor ID Structure profile enables authorized GPP users to define the structure of the CID.
This structure is unique to a specific direct debit scheme and can include discretionary data, which is
defined in the profile.
The profile, which is used by the CID Validation, defines the specific MOP to which the CID is related,
along with the maximum length of the CID and the beginning and ending positions of discretionary
data contained in the CID. Discretionary data is optional data that might be included in the CID. The
CID Validation removes this data to derive the CID key, which GPP uses during search and
identification processes.
4.1.4.2 Creditor ID Profile
The Creditor ID profile defines the relationship between a party and a CID.
4.1.4.3 Creditor ID Account Profile
The Creditor ID Account profile defines the relationship between a party’s direct debit accounts and a
CID.
4.1.4.4 Mandates Profile
GPP Mandate profiles are used to manually create mandates, which GPP uses to check the validity of
direct debits.
The Mandate profile page includes this information:
Unique mandate reference (UMR): Unique mandate identification code. GP uses this field and
the Creditor ID field to identify a mandate. When manually creating a mandate, an authorized
GPP user can type a value for this field. This field cannot be updated for an existing mandate.
Creditor ID: Unique creditor identification code. GPP uses this field and the UMR field to identify
a mandate. When manually creating a mandate, an authorized GPP user can type a value for this
field, which must pass validation by the Creditor ID Validation service. This field cannot be
updated for an existing mandate.
In addition, the Mandate Profile has the following tabs, each of which contains relevant fields used to
define a Mandate profile:
Mandate Profile - Details Tab: Provides information such as Mandate Signing Date,
Scheme/Scheme type, Recurrence type (One-Off/Recurring mandate), Mandate Cancellation
information, and Collection Rejection instructions.
Mandate Profile - Debtor/Creditor Tab: Provides detailed information about the Debtor/Creditor. It
includes Debtor/Creditor ID, Name, Account, Address, and BIC.
Mandate Profile - History Tab: Provides details of the Mandate history, such as
Mass Payments Business Setup
Global PAYplus Business Guide Page 66
o Maximum single collection amount allowed for a mandate
o Total amount of all collections allowed for a mandate
o Maximum number of collections
o Last amendment date triggered by incoming collection
o Last activity date of mandate which can be either collection on mandate, or mandate
deletion/update
o MID of the last collection of the mandate
For more information about mandates, see Mandate Management, Validation & Enrichment
4.1.4.5 Parameters Profile
The Parameters profile enables authorized GPP users to define the following:
Various parameters using a combination of scheme, party, and CID.
A level of validation that GPP performs on a CID, which can be one of the following:
o No Validation: GPP does not validate that the CID in an incoming direct debit is valid for the
defined party.
o Validate creditor ID: GPP validates that the CID in an incoming direct debit is valid for the
defined party.
o Validate creditor ID Account: GPP validates that the CID and the creditor ID account in an
incoming direct debit are valid for the defined party.
The type of Party Limit handling.
For more information about CIDs, see Creditor ID (CID) Validation (Incoming Flow)
4.1.5 Override STP Profiles
GPP uses Override STP profiles to prevent Straight-Through Processing (STP) of specific payments
that meet defined business rule conditions (see Mandate Validation Rules).
To implement mass payment direct debit functionality, the Override STP profile includes the following
fields:
Type: The type of STP Override profile, which is Mandate Validation. This is used to prevent STP
processing of a payment that does not have a valid mandate.
Error code: The relevant error code for the defined Type field.
For statuses of direct debit Override STP profiles, see Appendix B: STP Validation Error Statuses.
4.1.6 Interest Rates Profile
GPP Interest Rates profiles enable authorized GPP users to define monthly interest rates used by the
Compensation Calculation service to calculate the amount of compensation due on a direct debit
payment refund. For more information, see Compensation Calculation.
The Interest Rates profile has the following fields:
Interest type: Name of the specific Interest Types profile associated with the Interest Rates
profile.
Rate: Monthly interest rate, defined as a percent.
Year: Specific year of the defined interest rate.
Month: Specific month of the defined interest rate.
Mass Payments Business Setup
Global PAYplus Business Guide Page 67
4.1.7 Interest Types Profile
GPP Interest Types profiles are used to associate a MOP with defined interest rates, which the
Compensation Calculation uses to calculate the amount of compensation due on a direct debit
payment refund. For more information, see Compensation Calculation.
The Interest Types profile includes this information:
Name: Unique name used by GPP to identify each Interest Types profile.
Description: Description of the profile.
Method: Method used to calculate the number of days. One of the following method:
o 30 360: Calculations use a 30-day month and 360-day year.
o Actual 360: Calculations use the actual number of days in each month and a 360-day year.
o Actual 365: Calculations use the actual number of days in each month and a 365-day year.
Decimal digits: Number of digits after the decimal point in the calculated compensation amount.
4.1.8 Method of Payment Profile
GPP Method of Payment profiles enable authorized GPP users to control how GPP interacts with
each MOP defined in GPP.
The following fields in the Method of Payment profile, Processing tab, are relevant to mass payment
processing:
Bulking Profile: Define a Bulking profile for a MOP.
Interest Type: Associate an Interest Types profile with each MOP.
4.1.9 Parties Profile
GPP uses a Parties profile at the following stages of mass payment processing:
Initial File Validation: GPP checks that the initiating party (the party who sent the mass payment
file) is a FI’s customer.
Acknowledgment Reporting: GPP checks the file status reporting preferences for each of the
FI’s customers and generates a Customer Acknowledgment as defined in the Parties profile. GPP
uses the fields in the Acknowledgment section on the Preferences page in the Parties profile to
determine the types of Customer Acknowledgments to send to each customer. GPP also enables
a FI to define the version of the generated acknowledgment messages. For more information, see
Acknowledgment Reporting.
Acknowledgment Preference: Defines the type of acknowledgment messages (ACK and NAK)
that GPP automatically generates and sends to each customer. Possible values:
o None: GPP does not generate acknowledgment messages for incoming payments received
from the specific customer. This is the default value for each customer.
o Both ACK/NAK: GPP generates and sends both ACK and NAK messages for each incoming
payment received from the specific customer. GPP generates each ACK and NAK in the
defined customer-specific version.
o NAK Only: GPP generates and sends only NAK messages for incoming payments received
from the customer. GPP generates each NAK in the defined customer-specific version.
GPP generates and sends an acknowledgment message only if an Advising Type Selection rule
and an Interface Selection rule are evaluated and applied to a payment.
Mass Payments Business Setup
Global PAYplus Business Guide Page 68
Version: Defines the XSD version of the generated ACK and NAK messages. If a version is not
defined, GPP generates each ACK and NAK in the current version.
4.2 Rules
Each GPP business rule has a set of conditions and a related action. The conditions refer to attributes
of messages or other associated reference data in GPP. GPP performs the defined action if a
payment meets the defined rule conditions.
4.2.1 Advising Type Selection Rules
This rule is used to generate file status reports for FI customers at different stages of the processing
to enable the customers to track file and transaction processing. For more information, see
Acknowledgment Reporting.
4.2.2 Batch Validation
For each incoming mass payment file that GPP determines as valid (see Sub-Batch Filter Rules),
GPP invokes Batch Validation rules. GPP invokes these rules on each batch in a file. If a file meets
the defined conditions of a rule, GPP sets the batch with a status as defined in the rule’s action and
routes it to a specific queue for manual handling.
GPP invokes Batch Validation rules that do the following:
Verifies that the total calculated amount of all transactions in a batch is equal to the amount
defined in the batch header
Verifies that the actual number of transactions in a batch is equal to the number defined in the
batch header
Verifies that the number of rejected transactions in a batch does not exceed a defined percentage
of the total number of transactions in the batch
4.2.3 Bulking Sending Time Rules
This rule determines the time to generate and send outgoing files. Each sending time defined in the
Bulking profile must have a corresponding Bulking Sending Time rule.
This rule also enables authorized GPP users to define a last sending time for a specific message
type. For more information about Bulking profiles and sending times, see Bulking Profile.
GPP also enables authorized users to generate outgoing files containing groups of transactions that
have successfully completed processing and send them to a CSM, regardless of the defined sending
time.
4.2.4 File Department Rule
A rule type ‘department’ is invoked to assign department at a file level. Similar to department selection
at individual transaction level, the action to this rule is a department to be assigned to a file.
If no rule is found, the department is defaulted from the system parameter DEF_DEPT defined for
local office. Department Selection rules are also invoked for individual transactions in the file. There is
no direct relation between department at file level and departments at individual transaction level.
4.2.5 File Priority Rules
File Priority rules enable a bank to prioritize incoming mass payment files to determine the order in
which GPP processes each file. For example, a bank can define a rule that assigns a high priority to
Mass Payments Business Setup
Global PAYplus Business Guide Page 69
files received from a specific bank customer. When multiple files are waiting for processing, GPP first
processes files received from this customer.
Each File Priority rule is attached to a specific office.
These priority codes can be assigned by File Priority rules.
Code
Description
100
Lowest
200
Low
300
Low medium
400
Medium
500
High medium
600
High
700
Extra high
800
Special
900
Extra special
4.2.6 Incoming File Filter Rules
GPP Incoming File Filter rules enable a bank to prevent STP processing of an incoming mass
payment file. If GPP determines that an incoming file meets the conditions defined in an Incoming File
Filter rule, GPP stops processing the file and performs an action defined in the rule. A rule can have
one of the following actions:
Cancel: GPP cancels the incoming file.
Hold: GPP routes the incoming file to a queue for manual handling.
Reject: GPP rejects the incoming file.
For example, a bank can define a rule that holds all files received from a specific bank customer and
routes them to a queue for manual handling.
In addition to an action definition, each Incoming File Filter rule has an optional usage definition that
enables a bank to define an error code for each incoming file that meets the conditions of the rule.
GPP generates a file-level NAK to the initiating party, which contains error message details as
specific in the business rule.
GPP invokes Incoming File Filter rules after checking whether an incoming file is a duplicate. Each
Incoming File Filter rule is attached to an initiating party.
4.2.7 Parties Bulking Profile Selections Rules
Parties Bulking Profile Selections rules enable a FI to define multiple Bulking profiles for a single
MOP.
GPP invokes Parties Bulking Profile Selections rules during the Preprocessing flow to determine
whether a Bulking profile is defined to override a default Bulking profile. The default profile is defined
in the Method of Payment profile.
Note: Parties Bulking Profile Selections rules are defined to meet specific customer requirements and
are not included in the basic mass payment setup.
Mass Payments Business Setup
Global PAYplus Business Guide Page 70
For more information, see Bulking Profile.
4.2.8 Sub-Batch Filter Rules
GPP invokes Sub-Batch Filter rules on incoming mass payment files to prevent STP processing. If a
file meets the defined conditions of a rule, GPP sets the file with a status as defined in the rule’s
action and can do one of the following:
Route the file to a specific queue for manual handling
Reject the file
GPP invokes Sub-Batch Filter rules that do the following:
Verifies that the total calculated amount of all transactions in an incoming mass payment file is
equal to the amount defined in the file header
Verifies that the actual number of transactions in an incoming mass payment file is equal to the
number defined in the file header
Verifies that the number of rejected transactions in an incoming mass payment file does not
exceed a defined percentage of the total number of transactions in the file
4.2.9 Fee Type Selection Rule/Fee Formula Selection Rule
GPP invokes Fee Type Selection rules and Fee Formula rules to enable a FI to set fees on a specific
incoming payment or group of payments (S message). GPP enables authorized GPP users to set a
specific fee type or fee formula for the S message using the batch message type attribute or the batch
booking indicator.
4.2.10 Mandate Validation Rules
GPP invokes Mandate Validation rules to validate mandate-related attributes in mass payment direct
debit messages.
If GPP determines that a direct debit message meets the defined conditions of a Mandate Validation
rule, GPP does not process the message via STP, but instead rejects the payment message, as
defined in the Override STP profile for the specific Mandate Validation rule. The Override STP profile
must have a Mandate Validation type.
After the Mandate Validation selects the relevant mandate for a direct debit message, GPP begins
evaluating each Mandate Validation rule by the order of attachment. If a message’s attributes match
the defined rule conditions, GPP attaches the rule to the message. After a successful match, GPP
does the following:
Routes the direct debit message to the queue as defined in the relevant Override STP profile
Stops evaluating additional Mandate Validation rules
Authorized GPP users can attach Mandate Validation rules to the local office.
Mass Payments Appendix A: Mass Payment File Header
Global PAYplus Business Guide Page 71
Appendix A: Mass Payment File Header
GPP requires a specific XML file header to identify an incoming file as a mass payment file. The
following example shows the structure of an incoming mass payment file header for a pacs.008
payment.
<FTInbound:FTInBlkCredTrf xsi:schemaLocation="urn:FTInbound:xsd:$FTInBlkCredTrf
FTInBlkCredTrf.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:FTInbound="urn:FTInbound:xsd:$FTInBlkCredTrf">
<FTInbound:SndgInst></FTInbound:SndgInst>
<FTInbound:SndgMne>L</FTInbound:SndgMne>
<FTInbound:SndgNm></FTInbound:SndgNm>
<FTInbound:RcvgInst></FTInbound:RcvgInst>
<FTInbound:RcvgMne></FTInbound:RcvgMne>
<FTInbound:RcvgNm></FTInbound:RcvgNm>
<FTInbound:InitPtyId></FTInbound:InitPtyId>
<FTInbound:FileRef></FTInbound:FileRef>
<FTInbound:FSrc></FTInbound:FSrc>
<FTInbound:FType></FTInbound:FType>
<FTInbound:FDtTm></FTInbound:FDtTm>
<FTInbound:PDtTm></FTInbound:PDtTm>
<FTInbound:NumCTBlk></FTInbound:NumCTBlk>
<FTInbound:NumDDBlk></FTInbound:NumDDBlk>
<FTInbound:NumREJBlk></FTInbound:NumREJBlk>
<FTInbound:NumAPIBlk></FTInbound:NumAPIBlk>
<FTInbound:NumRFRBlk></FTInbound:NumRFRBlk>
<FTInbound:FundInd></FTInbound FundInd>
<FTInbound:SndgTm></FTInbound SndgTm>
<FTInbound:TtlDbtAmt></FTInbound TtlDbtAmt>
<FTInbound:TtlCdtAmt></FTInbound TtlCdtAmt>
<FTInbound:NumCTTrx></FTInbound NumCTTrx>
<FTInbound:NumDDTrx></FTInbound NumDDTrx>
<FTInbound:FIToFICstmrCdtTrf xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02">
The following table details the elements in a GPP mass payment file header.
XML Element
Field Name
Mandatory
Description
SndgInst
Sender Identifier
Yes
Main sender NCC code (without a
branch code)
SndgMne
Sender Mnemonic
Yes
Sender mnemonic
SndgNm
Sender Name
No
Sender name
RcvgInst
Receiver Identifier
Yes
NCC code
RcvgMne
Receiver Mnemonic
Yes
Mnemonic
RcvgNm
Receiver Name
No
Receiver name
InitPtyId
User Identifier
For PAIN
messages
only
User identifier
FileRef
File Reference
Yes
Unique file identifier
FSrc
File Source
Yes
Source system that sent the file
FType
File Type
Yes
File type
FDtTm
File Date and Time
Yes
File date and time
PDtTm
Processing Date
No
Processing date
NumCTBlk
Number of Credit
Instructions Bulks
Yes
Accumulated number of pacs.008 or
pain.001 bulks of in the file
Mass Payments Appendix A: Mass Payment File Header
Global PAYplus Business Guide Page 72
XML Element
Field Name
Mandatory
Description
NumDDBlk
Number of Debit
Instructions Bulks
Yes
Accumulated number of pacs.003 or
pain.008 bulks in the file
NumREJBlk
Number of pacs.002
Messages
Yes
Accumulated number of pacs.002
bulks in the file
NumAPIBlk
Number of camt.056
Payment Cancellation
Request bulks
Yes
Accumulated number of camt.056
bulks in the file
NumRFRBlk
Number of pacs.004
Messages
Yes
Accumulated number of pacs.004
bulks in the file
NumRFSBlk
Number of pacs.007
Reversal Bulks
Yes
Accumulated number of pacs.007
reversal bulks in the file
FundInd
Funding Indicator
Yes
Indicator that the file contains funding
messages, possible values:
1=Funding, 0=Non-Funding
SndgTm
Sending Time
No
Empty for incoming files
TtlDbtAmt
Total Debit Amount
Yes
Total amount of all debit transactions
in the file
TtlCdtAmt
Total Credit Amount
Yes
Total amount of all credit transactions
in the file
NumCTTrx
Total Credit Transaction
Count
Yes
Total number of all credit transactions
in the file
NumDDTrx
Total Debit Transaction
Count
Yes
Total number of all debit transactions
in the file
Mass Payments Appendix B: STP Validation Error Statuses
Global PAYplus Business Guide Page 73
Appendix B: STP Validation Error Statuses
The table lists the definitions for direct debit Override STP profiles.
Profile Name
Error
Code
Status
Mandate Not Found for Subsequent B2B Direct Debit
99010
Reject
Mandate Not Found for Subsequent Core Direct Debit
99010
Reject
Mandate Exists for First Time Direct Debit
99011
Invalid Mandate
Live Mandate Does Not Exist
99012
Invalid Mandate
Canceled Mandate
99013
Invalid Mandate
Mandate Scheme Does Not Match Direct Debit Scheme
99014
Invalid Mandate
Invalid Recurrence Type for B2B Mandate
99015
Invalid Mandate
Invalid Debtor Agent BIC
99017
Invalid Mandate
Invalid Debtor Agent Account
99016
Invalid Mandate
Invalid Sequence Type
99018
Invalid Mandate
Mandate Does Not Exist on Processing Day
99019
Reject
Live Mandate Does Not Exist on Processing Day
99019
Reject
Reject Collection Specified
99020
Reject
Maximum Amount Exceeded
99021
Invalid Mandate
Maximum Aggregate Amount Exceeded
99022
Invalid Mandate
Maximum Number of Collections Exceeded
99023
Invalid Mandate
Mass Payments Appendix C: Flow Legend
Global PAYplus Business Guide Page 74
Appendix C: Flow Legend
File Status
Message Status /Queue
Interface
Step
Sub Flow
Rule (Business/System)
Action button (from a queue)
Start/End/Previous/Next linkage points
Flow connection (dashed = optional)
Start
Cont
Button
Business
Rule
(Optional)
In File
Status
Message
Status
System Rule
Out File
Status
Sub-Batch
Status
Batch
Status
Related
Message
Status
Step Step with
inner
Processing
Interface
Sub Flow
Business
Rule
(Mandatory)
Mass Payments Appendix D: Glossary
Global PAYplus Business Guide Page 75
Appendix D: Glossary
This table describes the terms used in this document.
Term
Description
GPP
Global PAYplus
MP
Mass Payments
FI
Financial Institutions
ACH
Automated Clearing House
A system that receives and sends files of transactions from and to participating
parties, nets the amounts, and initiates settlement between banks.
CSM
Clearing and Settlement Mechanism
ACTC
File Acceptance. A file reason code indicating an accepted technical validation,
which means successful authentication, both syntactically and semantically.
BSA
Batch Suspense Account. A posting account used to accumulate transactions for
consolidated posting.
CID
Creditor ID. Unique creditor identification code supplied by a creditor bank. GPP
uses the CID and the UMR to identify a mandate.
DFI
Depository Financial Institution
A bank or other financial institution.
Direct Deposit
A credit transfer in a NACHA-based system.
Direct Payment
A direct debit in a NACHA-based system.
Gross
Accounting
Accounting method that performs postings for all transactions, regardless of
whether a transaction was processed, rejected, or canceled. Rejected and
canceled transactions are also posted separately as offsets to the account, either
in bulk (lump sum) or individually as defined in the party profile.
MOP
Method of Payment. The means via which a payment is executed, such as
BOOK or SWIFT
Net Accounting
Accounting method that performs postings for processed transactions only.
Posting is not performed for rejected or canceled transactions.
PART
Partial File Rejection. A file reason code indicating that one or more payments
are rejected.
PDO
Payment Data Object. Data object that holds all payment data, including:
XML message date (original and enriched)
Relational data
Reference data
Rates, fees, errors, and so on
R Message
GPP supports recall, return, and reject messages for both the originating bank
and the receiving bank.
RJCT
File Rejection. A file reason code indicating a rejected settlement, rejected
payment initiation, or rejected individual transaction.
RTGS
Real-Time Gross Settlement. A settlement system that transfers funds in real-
time, processes each transaction upon receipt, and settles each transaction
individually.
SEPA
Single Euro Payments Area. A European financial infrastructure that creates a
zone in which Euro payments (or any other agreed upon currency) are
considered domestic.
Mass Payments Appendix D: Glossary
Global PAYplus Business Guide Page 76
Term
Description
STEP2
The Pan-European Automated Clearing House (PE-ACH), a platform that
process bulk payments in euro.
STP
Straight-Through Processing. The concept that enables GPP to process
transactions to completion without the need for manual intervention. STP
enables shortened processing cycles, reduced settlement risk, and lower
operating costs.
SWIFT
A member-owned cooperative that provides the communications platform,
products, and services to connect over 8,600 banking organizations, securities
institutions, and corporate customers in more than 208 countries.
TPS
Transactions Per Second. The number of transactions GPP is able to process
per second.
UMR
Unique Mandate Reference. Unique mandate identification code supplied by a
creditor. GPP uses the UMR and the CID to identify a mandate.
CTO
Credit Transfer Outgoing
DDO
Direct Debit Outgoing

Navigation menu