Business Guide GPP Mass Payments DD

User Manual: Pdf

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

DownloadBusiness Guide GPP Mass Payments - DD
Open PDF In BrowserView PDF
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

Version Control
Version

Date

1.0

Summary of Changes
Document Created

2.0

August 2015

New structure and amended contents

3.0

November 2015

Updated for rebranding

Global PAYplus Business Guide

Page 3

Mass Payments

Table of Contents

Table of Contents
1

INTRODUCTION .......................................................................................................................... 6
1.1
1.2
1.3
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.4

2

Overview ............................................................................................................................... 6
Mass Payments File Levels .................................................................................................. 6
Message Types ..................................................................................................................... 7
Payment Initiation .............................................................................................................. 7
Payment Clearing and Settlement .................................................................................... 7
Exceptions and Investigations ........................................................................................... 8
Bank to Customer Cash Management .............................................................................. 8
Credit Transfer R Messages ............................................................................................. 8
Direct Debit R Messages ................................................................................................... 9
Mixed Files ........................................................................................................................ 9
GPP Message Types Terminology ....................................................................................... 9

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
3.2
3.3
3.3.1
3.3.2
3.3.3
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5

Manual Repair ..................................................................................................................... 58
Manual Repair Accounting .................................................................................................. 58
Manual Cancellation ........................................................................................................... 58
Incoming File Cancellation .............................................................................................. 58
Incoming Batch Cancellation ........................................................................................... 59
Incoming Transaction Cancellation and Reversal ........................................................... 60
GPP Mass Payments User Interface .................................................................................. 61
File Summary .................................................................................................................. 61
Batch Summary ............................................................................................................... 62
Pending Outgoing Files Summary................................................................................... 63
Pending Outgoing File ..................................................................................................... 63
Transaction Data ............................................................................................................. 63

Global PAYplus Business Guide

Page 4

Mass Payments

4

Table of Contents

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

Global PAYplus Business Guide

Page 5

Mass Payments

1

Introduction

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.



1.2

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.

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)

Global PAYplus Business Guide

Page 6

Mass Payments


Introduction

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.

Global PAYplus Business Guide

Page 7

Mass Payments

Introduction

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.
R-Message

Initiating Party

Description

Recall

Debtor Bank

A debtor bank requests to cancel a previously transmitted
credit transfer.

Rejection

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.

Return

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 postsettlement transaction that cannot be processed to completion.

Global PAYplus Business Guide

Page 8

Mass Payments

Introduction

R-Message

Initiating Party

Description

Recall
Rejection

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.

Global PAYplus Business Guide

Page 9

Mass Payments

Introduction

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.

Global PAYplus Business Guide

Page 10

Mass Payments

2

Processing

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.
File Processing

2.1.1.1

File Processing Workflow

File

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 3 of 35

Rejected

Start

Cont

File Parsing/
Validations

Global PAYplus Business Guide

Create
Batch
Summary

File
Department
Selection

File Priority

File
Duplicate
Check

MatchingCheckService
Sub Type = Orig
File^Duplicate

Page 11

Mass Payments

Processing

File Processing II

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 4 of 35

2.1.1.2

Rejected

Distributed

Release

Not Valid
InitgPty

Rejected

Release

Hold

Cancelled

Distributed

Back

Cont

Validate
Initiating
Party

Incoming
File Filter
Rules

Split file to
processing
group
(chunks)

Business
Flow
Selection

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.

Global PAYplus Business Guide

Page 12

Mass Payments


Processing

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.

Global PAYplus Business Guide

Page 13

Mass Payments

2.1.1.8

Processing

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.

Global PAYplus Business Guide

Page 14

Mass Payments

2.1.2.1

Processing

Payment Initiation

For a detailed description of the Payment Initiation, see Payment Initiation Business Guide.
Pre Processing - Payment Initiation I (I)

Payment Initiation Workflow

Page 5 of 35

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

2.1.2.1.1

2.1.2.1.2

Submit

Wait Rate

Repair

Submit

Repair

Cancel

Business
Flow
Selection

Flow
Management

Single
Message
Flow

Bacl

Cont

Map
Payment
Info

Rate usagebase
conversion

Repair And
Enrichment

Party Detail
Enrichment

Sets...
MID
Msg Class
Office
Department
Product code etc..

Message
Duplicate
Check

Crisis Check

Source MOP
STP
Validation

Office SLA

MatchingCheckService
Sub Type = OrigInal
Payment^Duplicated

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.

Global PAYplus Business Guide

Page 15

Mass Payments

Processing

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.

Global PAYplus Business Guide

Page 16

Mass Payments

2.1.2.1.9

Processing

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

Pre Processing - Debit Party Processing (I)

Debit Party Workflow

Page 6 of 35

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

2.1.2.2.1

Submit

Repair

Cancel

Flow
Management

Cont

Back

2.1.2.2.1.1

Incoming
Return/
Reject
Matching

Find 1st in
Chain

Load Party

Account
Derivation

SLA- Debit
party

Debit
Authorization

Rate usage
for debit side
conversion

Batch Booking=’False’

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.

Global PAYplus Business Guide

Page 17

Mass Payments

2.1.2.2.1.4

Processing

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.
Pre Processing - Credit Side Processing (I)

2.1.2.2.2

Credit Side Workflow

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 7 of 35

Submit

Repair

Cancel

Flow
Management

Start

Cont

Credit Party
Processing

Global PAYplus Business Guide

Party Detail
Enrichment

Dest MOP
STP
Validation

Transfer
method
identification

Multi Office
– Re invoke
Destination
Party

Applicable for bank routing

Page 18

Mass Payments

2.1.2.2.2.1

Processing

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.

Global PAYplus Business Guide

Page 19

Mass Payments

2.1.2.3

Processing

Post MOP

Pre Processing - Post MOP (I)

Post MOP Workflow

Page 8 of 35

Manual Handling

Integration

External
Systems

2.1.2.3.1

Cancel

Wait
Sched Sub
Batch

Wait SubBatch

Global PayPlus Services
Platform

Future
Date

2.1.2.3.2

Compliance
request - file
buffer

Processing
date

Flow
Management

Start

Cont

Debit
Transaction
code

Credit
Transaction
code

Prevent STP

Fees
(itemized)

Compliance
Validation

Batch Booking=’False’

Generate Sub
Batch

Batch compliance request

Accumulate transaction
according to grouping ID

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

Global PAYplus Business Guide

Page 20

Mass Payments

Processing

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

Global PAYplus Business Guide

Page 21

Mass Payments

Processing

Sub Batch Generation (S)

Sub Batch Generation (S) Workflow

Page 9 of 35

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

2.1.3.1

Start

Cont

Rate usage
for debit side
conversion

Debit
Authorization

Value Date

Debit
Transaction
Codes

Credit
Transaction
code

Fees
(Sub-Batch)

Batch Booking=’True’

Batch Booking=’True’
Recalculate Value Date

Sub Batch Generation II (S)

Integration

External
Systems

Page 10 of 35

Global PayPlus Services
Platform

Manual Handling

Balance
Inquiry

FX Engine
Interface

Submit
Retry

FX Repair

NSF

Force

Wait BI

Schedule

Wait FX

Flow
Management

Complete

Flow
Management

Future Dated

Back

Cont

Debit hold
until time

Interface
Selection

Global PAYplus Business Guide

Stop Flag

Compliance
Check

External FX
(Lump Sum)

Postingconsolidated
(first leg)

Flow
Management

Page 22

Mass Payments

2.1.3.2

Processing

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.

Global PAYplus Business Guide

Page 23

Mass Payments

Processing

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.

Global PAYplus Business Guide

Page 24

Mass Payments

Processing

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.
Execution (I)

2.1.4.1

Execution Workflow

Integration

External
Systems

Page 11 of 35

Global PayPlus Services
Platform

Manual Handling

Balance
Inquiry

FX Engine
Interface

Retry

Submit

NSF

FX Repair

Force

Hold

Wait BI

Flow
Management

Schedule

Flow
Management

Flow
Management

Future Dated
Back

Hold Until
Time

Interface
Selection

Stop Flag

Compliance
Check

Batch Booking= ‘False’

2.1.4.2

Wait FX

External FX
(Individual)

No Bulking
Profile

Execution Individuals

Bulking Profile
Exists

Execution Bulking
Profile

Postingitemized
(customer
leg)

Batch Booking= ‘False’

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.

Global PAYplus Business Guide

Page 25

Mass Payments

2.1.4.5

Processing

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.
Execution - Destination Single (I)

2.1.5.1

Execute Individual Files Workflow

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 12 of 35

2.1.5.2

Service
Release

Flow
Management

Negative

CTO
Negative
Response
Flow

Positive

CTO
Positive
Response
Flow

Unmatched
Back

Liquidity

Posting
(Individual
Credit)

Format Out
And
Transmission

Match
Response to
Payment

End

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

Global PAYplus Business Guide

Page 26

Mass Payments

2.1.5.4

Processing

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.
Execution - Destination Bulk (I)

2.1.6.1

Execute Bulk Workflow

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 13 of 35

Complete

End

Back

Out bulk
grouping ID
selection

Bulking
sending time

Global PAYplus Business Guide

Posting
(Individual
Credit)

Flow
Management

Consolidated
Accounting=No

Out File
Generation

Generate ‘A’ message
based on following fields
- MOP
- Sttlm Acct
- Sttlm Dt

Posting
(Consolidated
Credit)

Match
Response to
Payment

Response
Handling

Consolidated
Accounting=Yes

Page 27

Mass Payments

2.1.6.2

Processing

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.

Global PAYplus Business Guide

Page 28

Mass Payments

2.1.6.7

Processing

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
2.1.6.9.1

Response Handling
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:

Global PAYplus Business Guide

Page 29

Mass Payments





Processing

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
2.1.8.1

Mass Payments Accounting
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.

Customer Leg
(Debit
Customer)

Accounting Model

Description

Exceptions Scenarios

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 preprocessing)
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 preprocessing/in repair/
sanctions hold.

Any payments
rejected/cancelled after
posting are posted
separately as offsets to
the account (reverse
accounting).

Global PAYplus Business Guide

Page 30

Mass Payments

Clearing
Leg/Book
(Credit
Settlement
account)

2.1.8.2

Customer Leg
(Credit
Customer)

2.2.1

Accounting Model

Description

Exceptions Scenarios

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

Inward Credit Transfer Accounting Models

Clearing Leg
(Debit
Settlement
account)

2.2

Processing

Accounting Model

Description

Exceptions Scenarios

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

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

Direct Debit Process
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.

Global PAYplus Business Guide

Page 31

Mass Payments

Processing

File Processing

2.2.1.1

File Processing Workflow

File

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 3 of 35

Rejected

Start

Cont

Create
Batch
Summary

File Parsing/
Validations

File
Department
Selection

File
Duplicate
Check

File Priority

MatchingCheckService
Sub Type = Orig
File^Duplicate

File Processing II

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 4 of 35

Rejected

Distributed

Release

Not Valid
InitgPty

Rejected

Release

Hold

Cancelled

Distributed

Back

Cont

Validate
Initiating
Party

Global PAYplus Business Guide

Incoming
File Filter
Rules

Split file to
processing
group
(chunks)

Business
Flow
Selection

Page 32

Mass Payments

2.2.1.2

Processing

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.

Global PAYplus Business Guide

Page 33

Mass Payments

Processing

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.

Global PAYplus Business Guide

Page 34

Mass Payments

Processing

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.

Global PAYplus Business Guide

Page 35

Mass Payments

Processing

Pre Processing - Payment Initiation I (I)

Payment Initiation Workflow

Page 5 of 35

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

2.2.2.1.1

2.2.2.1.2

Submit

Wait Rate

Repair

Submit

Repair

Cancel

Business
Flow
Selection

Flow
Management

Single
Message
Flow

Bacl

Cont

Map
Payment
Info

Rate usagebase
conversion

Repair And
Enrichment

Party Detail
Enrichment

Sets...
MID
Msg Class
Office
Department
Product code etc..

Message
Duplicate
Check

Crisis Check

Source MOP
STP
Validation

Office SLA

MatchingCheckService
Sub Type = OrigInal
Payment^Duplicated

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

Global PAYplus Business Guide

Page 36

Mass Payments

Processing

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.

Global PAYplus Business Guide

Page 37

Mass Payments

2.2.2.1.9

Processing

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

Pre Processing - Credit Party Processing (I)

2.2.2.2.1

Credit Party Workflow

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 6 of 34

Submit

Repair

Cancel

Flow
Management

Cont

Back

2.2.2.2.1.1

Find 1st in
Chain

Load Party

Account
Derivation

Mandate
Validation
and
Enrichment

SLA- Credit
party

Rate usage
for credit side
conversion

If creditor mandate check is
required

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)

Global PAYplus Business Guide

Page 38

Mass Payments

Processing

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:

Global PAYplus Business Guide

Page 39

Mass Payments

Processing



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.

Global PAYplus Business Guide

Page 40

Mass Payments

Processing

Pre Processing - Debit Side Processing (I)

2.2.2.2.2

Debit Side Workflow

Global PayPlus Services
Platform

Manual Handling

Integration

External
Systems

Page 7 of 34

2.2.2.2.2.1

Submit

Repair

Cancel

Flow
Management

Start

Cont

Debit Party
Processing

Party Detail
Enrichment

Creditor ID
Validation

Dest MOP
STP
Validation

Multi Office
– Re invoke
Destination
Party

Mandate
Validation

Debit Mandate
validation

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

Global PAYplus Business Guide

Page 41

Mass Payments

Processing



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.

Global PAYplus Business Guide

Page 42

Mass Payments

2.2.2.2.2.5

Processing

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.

Global PAYplus Business Guide

Page 43

Mass Payments

2.2.2.3

Processing

Post MOP

Pre Processing - Post MOP (I)

Post MOP Workflow

Page 8 of 35

Manual Handling

Integration

External
Systems

2.2.2.3.1

Cancel

Wait
Sched Sub
Batch

Wait SubBatch

Global PayPlus Services
Platform

Future
Date

2.2.2.3.2

Compliance
request - file
buffer

Processing
date

Flow
Management

Start

Cont

Debit
Transaction
code

Credit
Transaction
code

Prevent STP

Fees
(itemized)

Compliance
Validation

Batch Booking=’False’

Generate Sub
Batch

Batch compliance request

Accumulate transaction
according to grouping ID

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.

Global PAYplus Business Guide

Page 44

Mass Payments

2.2.2.3.5

Processing

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

Global PAYplus Business Guide

Page 45

Mass Payments

2.2.3.1

Sub Batch Generation (S) Workflow

2.2.3.2

Rate Usage for Debit Side Conversion

Processing

GPP uses Rate Usage rules to determine the relevant foreign currency exchange rate for each
transaction, if a currency conversion is required.

Global PAYplus Business Guide

Page 46

Mass Payments

Processing

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.

Global PAYplus Business Guide

Page 47

Mass Payments

Processing

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.

Global PAYplus Business Guide

Page 48

Mass Payments

2.2.4.1

Execution Workflow

2.2.4.2

Hold Until Time

Processing

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.

Global PAYplus Business Guide

Page 49

Mass Payments

Processing

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
2.2.5.6.1

Response
DDO Negative Response

Upon receipt of a negative response, the DDO is routed to the Reject queue.

Global PAYplus Business Guide

Page 50

Mass Payments

2.2.5.6.2

Processing

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.

Global PAYplus Business Guide

Page 51

Mass Payments

2.2.6.3

Processing

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
2.2.6.9.1

Response Handling
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.

Global PAYplus Business Guide

Page 52

Mass Payments

2.2.7

Processing

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.

Global PAYplus Business Guide

Page 53

Mass Payments


Processing

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

2.2.8.3.2

508.45

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

Global PAYplus Business Guide

508.33

Page 54

Mass Payments

2.2.8.3.3

Processing

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

2.2.9
2.2.9.1

508.36

Mandate Management, Validation & Enrichment
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:

Global PAYplus Business Guide

Page 55

Mass Payments




Processing

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.

Global PAYplus Business Guide

Page 56

Mass Payments

Processing

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

Global PAYplus Business Guide

Page 57

Mass Payments

3

Manual Handling

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.

Global PAYplus Business Guide

Page 58

Mass Payments

Manual Handling

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.

Global PAYplus Business Guide

Page 59

Mass Payments

Manual Handling



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.

Global PAYplus Business Guide

Page 60

Mass Payments

Manual Handling



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
3.4.1.1

File Summary
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.

Global PAYplus Business Guide

Page 61

Mass Payments

3.4.1.3

Manual Handling

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

Global PAYplus Business Guide

Page 62

Mass Payments

3.4.3

Manual Handling

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.

Global PAYplus Business Guide

Page 63

Mass Payments

4

Business Setup

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

Global PAYplus Business Guide

Page 64

Mass Payments

Business Setup



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

Global PAYplus Business Guide

Page 65

Mass Payments

Business Setup

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.

Global PAYplus Business Guide

Page 66

Mass Payments

4.1.7

Business Setup

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.

Global PAYplus Business Guide

Page 67

Mass Payments


Business Setup

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

Global PAYplus Business Guide

Page 68

Mass Payments

Business Setup

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.

Global PAYplus Business Guide

Page 69

Mass Payments

Business Setup

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.

Global PAYplus Business Guide

Page 70

Mass Payments

Appendix A: Mass Payment File Header

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.


L























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

Global PAYplus Business Guide

Page 71

Mass Payments

Appendix A: Mass Payment File Header

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

Global PAYplus Business Guide

Page 72

Mass Payments

Appendix B: STP Validation Error Statuses

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

Global PAYplus Business Guide

Page 73

Mass Payments

Appendix C: Flow Legend

Appendix C: Flow Legend
Message
Status

Sub-Batch
Status

Related
Message
Status

In File
Status

Out File
Status

Batch
Status

Step with
inner
Processing

Step

Step
Sub Flow

Sub Flow

Business
Rule
(Optional)

System Rule

Rule (Business/System)
Action button (from a queue)

Button

Cont

File Status
Interface

Interface

Business
Rule
(Mandatory)

Message Status /Queue

Start

Start/End/Previous/Next linkage points
Flow connection (dashed = optional)

Global PAYplus Business Guide

Page 74

Mass Payments

Appendix D: Glossary

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 realtime, 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.

Global PAYplus Business Guide

Page 75

Mass Payments

Appendix D: Glossary

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

Global PAYplus Business Guide

Page 76



Source Exif Data:
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Language                        : en-US
Tagged PDF                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26
Format                          : application/pdf
Creator                         : D+H
Description                     : Mass Payments
Title                           : Business Guide
Create Date                     : 2016:06:30 14:03:33+03:00
Creator Tool                    : Microsoft® Word 2013
Modify Date                     : 2016:06:30 14:03:52+03:00
Metadata Date                   : 2016:06:30 14:03:52+03:00
Producer                        : Microsoft® Word 2013
Document ID                     : uuid:c35662de-1076-4117-a29a-c969604b4e8a
Instance ID                     : uuid:68c3b720-b3d4-4df0-8402-5af621b4fa8c
Page Mode                       : UseOutlines
Page Count                      : 76
Author                          : D+H
Keywords                        : Global, PAYplus
Subject                         : Mass Payments
EXIF Metadata provided by EXIF.tools

Navigation menu