Business Guide GPP Clearing Processing

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 156 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Global PAYplus Version 4.6.6
Clearing Processing
Business Guide
Copyright
© 2009-2017 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-B31-07-201706
Clearing Processing Version Control
Global PAYplus Business Guide Page 3
Version Control
Version Date Summary of Changes
1.0 Document created with MEPS, Target2, Euro1 and UK CHAPS
2.0 Oct 2015 Added Multi Office setup, Australia RITS PDS, Hong Kong CHATS,
removed Statement Messages section under MEPS
3.0 Dec 2015 Added Australia - RITS PDS, New Zealand - HVCS, Malaysia -
RENTAS and Ripple
4.0 Mar 2015 Added Immediate Payments - NPP and Mass Payments - AC
5.0 Jun 2016 Updated Malaysia - RENTAS
6.0 Dec 2016 Update Australia - NPP, added Mass Payments, Austria - CS.A
7.0 April 2017 Added Australia - Austraclear to Single Payment APAC Clearing;
updated Australia - RITS
Clearing Processing Table of Contents
Global PAYplus Business Guide Page 4
Table of Contents
1 INTRODUCTION ................................................................................................................ 5
1.1 Target Audience........................................................................................................... 5
2 GENERIC CLEARING PROCESSING ................................................................................. 6
2.1 SWIFT Based Message Types and Processing .............................................................. 6
2.1.1 SWIFT Message Types ............................................................................................. 6
2.1.2 FINCopy .................................................................................................................. 7
3 SINGLE PAYMENT CLEARINGS ....................................................................................... 7
3.1 Generic Processing ...................................................................................................... 7
3.1.1 Y-Copy RTGS Flow Processes .................................................................................. 8
3.1.2 Message Types ........................................................................................................ 9
3.2 Single Payment EU Clearing ....................................................................................... 10
3.2.1 TARGET2 .............................................................................................................. 10
3.2.2 EURO1 .................................................................................................................. 16
3.2.3 UK CHAPS............................................................................................................. 21
3.3 Single Payment APAC Clearing .................................................................................. 29
3.3.1 Australia - RITS PDS .............................................................................................. 29
3.3.2 Australia - RITS Austraclear .................................................................................... 38
3.3.3 New Zealand - HVCS .............................................................................................. 51
3.3.4 Hong Kong - CHATS............................................................................................... 58
3.3.5 Singapore - MEPS .................................................................................................. 67
3.3.6 Malaysia - RENTAS ................................................................................................ 71
4 MASS PAYMENT CLEARINGS ........................................................................................ 77
4.1 Mass Payment EU Clearing ........................................................................................ 77
4.1.1 Austria - CS.A ........................................................................................................ 77
4.2 Mass Payment Africa Clearing .................................................................................... 86
4.2.1 South Africa - AC .................................................................................................... 86
4.3 Mass Payment APAC Clearing...................................................................................110
4.3.1 Malaysia - IBG .......................................................................................................110
5 DISTRIBUTED LEDGER PAYMENT PROCESSING .........................................................144
5.1 Clearing Processing on Distributed Payment Environment ...........................................144
5.1.1 Ripple ...................................................................................................................144
APPENDIX A: GLOSSARY .......................................................................................................152
Clearing Processing Introduction
Global PAYplus Business Guide Page 5
1 Introduction
Note: This guide has not yet been certified for GPP V4.6; therefore, there may be inaccuracies in this
document that may require amendments in the future. For more information, please contact your D+H
Project Manager.
This business guide describes the processing of clearing houses (local or regional) and SWIFT certified
by Global PAYplus (GPP). The details provided is additional information specific for the clearings, on top
of the offering, for example, Single Payment, Mass Payment, Immediate Payment.
1.1 Target Audience
This business guide is designed for business analysts and system administrators who need understand
the clearings supported by GPP. It is also of value to anyone who wants to know more about how this
feature is implemented. A basic understanding of GPP functionality is assumed.
For a list of terms and their definitions used in this document, see Appendix A: Glossary.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 6
2 Generic Clearing Processing
2.1 SWIFT Based Message Types and Processing
GPP processes and handles SWIFT payments as described in this section and supports FINcopy and
cross-border SWIFT payments.
2.1.1 SWIFT Message Types
This table lists the SWIFT Message Types supported in GPP.
Note: For format and rules, refer to the SWIFT Book, Category 1 to 9.
Message
Type Sub
Type Description
103 Single customer credit transfer. It may only be used for clean payment
instructions. It conveys a funds transfer instruction in which the ordering
customer and/or the beneficiary customer are non-financial institutions from the
perspective of the Sender.
103 PLS Single customer credit transfer. The PLS refers to payment STP, which allows
the exchange of single customer credit transfers using a restricted set of fields
and format options of the core MT103.
190 Advice of Charges, Interest and Other Adjustments.
191 Request for payment of charges, interest and other expenses.
192
Request for cancellation.
195 Queries.
196 Answers.
198 Inward direct debit and inward credit transfer for HV (high value) payments
199 Free format message - message used by Financial Institution to send or receive
Information.
202 General Financial Institution transfer. It is used to order the movement of funds
to the beneficiary institution.
This message may also be sent to a financial institution servicing multiple
accounts for the Sender to transfer funds between these accounts. In addition, it
can be sent to a financial institution to debit an account of the Sender serviced
by the Receiver and to credit an account, owned by the Sender at an institution
specified in field 57a.
202 COV General Financial Institution transfer.
205 Financial institution transfer execution. It is used to further transmit a funds
transfer instruction domestically.
210 Notice to receive. A notice in advance for the account servicing institution that it
receives funds to be credited to the Sender's account.
290 Advice of charges, interest and other adjustments.
291 Request for payment of charges, interest and other expenses.
292 Request for payment cancellation.
295 Queries.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 7
Message
Type Sub
Type Description
296 Answers.
299 Free Format Message - message used by Financial Institution to send or receive
Information.
900 Confirmation of Debit. Advises an account owner of a debit to its account.
910 Confirmation of Credit. Advises an account owner of a credit to its account.
2.1.2 FINCopy
SWIFTNet is a secure, dedicated, global communication network that supports a range of financial
messaging services, which includes the FIN store-and-forward message-processing service.
FIN provides users with a wide range of message types for transaction and information processing and
settlement. FIN messages consist of structured headers, text, and trailers, and conform to internationally
accepted standards. SWIFT protects the confidentiality, integrity, and authenticity of FIN messages.
FINCopy is a message duplication service. SWIFT developed FINCopy to assist financial communities in
implementing centralized systems, for example, Real-Time Gross Settlement (RTGS) or netting systems.
2.1.2.1 FINCopy Service Modes
The FINCopy service can operate in the following modes:
• In Y-Copy mode, FINCopy copies messages to the service administrator, and stores these messages
until it receives authorization or refusal from the service administrator.
• In T-Copy mode, FINCopy copies messages to the service administrator and immediately forwards
the messages for delivery to the receiver.
• In Bypass mode, FINCopy does not copy the messages to the service administrator
In normal operations, FINCopy operates in either Y-Copy or T-Copy mode. SWIFT reserves Bypass
mode for specific, abnormal situations.
2.1.2.2 FINCopy Service Code
The FINCopy service code parameter is a unique Identifier which the user that participates in a FINCopy
closed user group inserts into field 103 of the user header, to identify a message for FINCopy.
FIN also uses this parameter in undelivered message reports, for the same purpose. Single Payment
Clearings
For a detailed description of the Single Payment flows, use cases and processes, see GPP Business
Guide Single Payment.
2.2 Generic Processing
The selection of a clearing for an outward payment is performed in the MOP selection process.
The identification of the clearing for an inward payment is performed in the debit side processing.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 8
2.2.1 Y-Copy RTGS Flow Processes
This is the flow processes for Y-Copy RTGS. It is the same flow for all Y-Copy RTGS service types (for
example, Target2, EURO1) and supported by GPP.
MT Outward/
Inward Processing
Flow Clearing
Response GPP Queue Comments
103, 103+,
202,
202COV
Outward
to clearing Outward to
clearing before
cut-off time
No response
from clearing Wait
confirmation The queue is
configurable
Outward
to clearing Outward to
clearing before
cut-off time
MT012
(sender
notification)
from clearing
Complete
Outward
to clearing Outward to
clearing before
cut-off time
MT019
(abort
Notification)
from clearing
Reject MT019 is received
when:
SWIFT cannot
deliver the message
to the clearing
The clearing refuses
to settle the
transaction
Clearing accepted
the message but
cannot deliver it to
the receiver
The queue is
configurable
Outward
to clearing Outward to
clearing after
cut-off time
(warehouse in
GPP)
N/A Scheduled
Outward
to clearing Outward to
clearing after
cut-off time (no
warehouse in
GPP)
MT012
(sender
notification)
from clearing
Complete As clearing accepts
future payments up
to 14 business days
in advance
Outward
to clearing Outward to
clearing invalid
format
SWIFT NAK Repair The queue is
configurable
Outward
to clearing Outward to
clearing
duplicate
MT019
(abort
Notification)
from clearing
Reject The queue is
configurable
Outward
to clearing Outward to
clearing but
insufficient
funds
MT019
(abort
Notification)
from clearing
Repair The queue is
configurable
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 9
MT Outward/
Inward Processing
Flow Clearing
Response GPP Queue Comments
103, 103+,
202,
202COV
Inward
from
clearing
Inward STP
payment from
clearing
N/A Complete
Inward
from
clearing
Inward Non-
STP payment
from clearing
N/A Repair GPP send the
payment to manual
intervention queue.
The user can correct
the payment or send
Return/Reject to
clearing
MT012
Inward
from
clearing
Inward MT012 N/A Complete The payment is
matched and added
to original payment.
MT019
Inward
from
clearing
Inward MT019 N/A Reject Payment is matched
and added to original
payment. Original
payment is routed to
Rejected queue.
The queue is
configurable
MT900 Inward
from
clearing
Inward debit
notification N/A Complete The payment is
matched and added
to original payment
MT910
Inward
from
clearing
Inward credit
notification N/A Complete The payment is
matched and added
to original payment
MT940/950 Inward
from
clearing
Inward
statement N/A Complete Update the closing
and available
balance
2.2.2 Message Types
Message types supported for High Value Y copy (SWIFT based Fin messages) clearing are:
• MT103
• MT103+
• MT202
• MT202COV
• MT012
• MT019
• MT900
• MT910
• MT940/950
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 10
2.3 Single Payment EU Clearing
2.3.1 TARGET2
2.3.1.1 Overview
TARGET2 (Trans-European Automated Real-time Gross Settlement Express Transfer System) is the
real-time gross settlement (RTGS) system owned and operated by the Eurosystem. This interbank
payment system is used for the real-time processing of cross-border transfers throughout the European
Union.
TARGET2 is operated on a single technical platform. The business relationships are established between
the TARGET2 users and their National Central Bank. In terms of the value processed, TARGET2 is one
of the largest payment systems in the world.
The TARGET2 directory lists the institutions that can be addressed in TARGET2. It contains Direct and
Indirect participants’ BIC addresses. The Directory provides the routing information for TARGET2
payments and is organized alphabetically by institution.
Additional Information related to TARGET2:
Information Value
FIN Copy service identifier code TGT
Service Type Y-Copy
Currency code EUR
Operating hours of TARGET2 Start of the business day (06:45 – 19:00)
Night-time settlement (NTS) procedures (19:30 – 07:00)
Business window (06:45 – 07:00)
Day trade phase (07:00 – 18:00)
Cut-off time 17:00: customer payments cut-off time
18:00: interbank payments cut-off time
Special Processing Tag {113:4!x} banking priority
Character 1:
H = highly urgent payment
U = urgent payment
N = normal payment
Character 2:
Y = MT012 requested
N = MT012 not requested
Character 3 + 4: Not used and not checked
In TARGET2, the default value for field 113 is NYNN (normal
payment, MT012 requested)
2.3.1.2 Inward/Outward Processing
2.3.1.2.1 Inward Processing from TARGET2
1. A payment received from TARGET2 has these values:
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 11
o Sender = TARGET2 member BIC
o Fin copy service in field 103 block 3 = TGT
2. When GPP identifies the values in step 1, the Debit MOP is set to TARGET2.
3. Debit MOP validation is performed as per MOP attributes.
4. Debit account is set to TARGET2 settlement account.
2.3.1.2.2 Outward Processing to TARGET2
1. When Target2 is selected as the credit MOP, GPP performs MOP validation.
For example:
o Settlement currency (SWIFT tag 32A) is EUR
o Settlement date (SWIFT tag 32A) is within the range available for TARGET2
o As membership validation is required for TARGET2 (setup in the MOP profile), GPP checks that
the first in credit chain is a member or associate member of TARGET2
2. If validation is successful and MOP TARGET2 is selected by the rule, then GPP sends the payment
with the following enrichments:
o Field 103 in block 3 (Fin copy) is be set to TGT
o Local office BIC (defined as the MOP identifier) is written as the sender in block 1
o Field 113 with a default value of NYNN unless setup differently
SWIFT standard validations are applied on outgoing payments to TARGET2.
Outgoing payments that missed TARGET2 cut-off time and no other relevant MOPs are available are
stored in the Scheduled queue and processed on the next business day.
2.3.1.3 Flow Processes with TARGET2
The flow process for all Y-Copy RTGS is the same and supported by GPP. As TARGET2 is a Y-Copy
service type, see Y-Copy RTGS Flow Processes for a description of the process.
2.3.1.4 Business Setup
Setup Additional Information
System Parameters N/A
Profiles MOP, Cut Off Times, Membership, Identifiers. Profiles
Rules MOP selection, Clearing Cut-off Rules
Permissions N/A
Tasks N/A
Queues N/A
2.3.1.5 Profiles
These are the details of the required setup in GPP profiles for the Clearing Certification.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 12
2.3.1.5.1 Method of Payment Profile - Single Office Setup
To successfully identify the local office and the debit MOP, when an incoming message is received from
TARGET2, the local office’s BIC (provided in Block 1 of the incoming payment) needs to be set as a valid
identifier for this MOP in the MOP profile.
TARGET2 can be setup in GPP as a EUR Method of Payment. A respective MOP selection rule needs to
be created to define the scenarios in which TARGET2 is selected.
These are the specific attributes that need to be defined in the Method of Payment profile for TARGET2
Clearing.
Field Value for TARGET2 Comment
Name TARGET2
Calendar Relevant calendar or no value
MOP Business Date Current business day for the
MOP The business date can be changed
manually or by an end-of-day task
that advances the MOP business
date to the next valid business date
for the MOP.
Currency EUR
Settlement accounting TARGET2 settlement account
Membership Required Must be selected
Membership type MOP
Send outgoing message Must be selected
Settlement account exists Must be selected
Processing Tab
FIN copy service TGT
Communication preferences Wait for confirmation
2.3.1.5.2 Method of Payment Profile - Multi Office Setup
For multi office setup, the list of MOPs in the MOP selection of the indirect Office includes MOP EURO1
as the Multi Office MOP. When this MOP is selected, a payment is sent to EURO1 where the Sender is
the direct participant.
Field Value for Direct Participant Office
Name TARGET2
Calendar Relevant calendar or no value
MOP Business Date Current business day for the MOP
Currency EUR
Settlement accounting TARGET2 settlement account in office Y
Membership Required Must be selected
Membership type MOP
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 13
Field Value for Direct Participant Office
Send outgoing message Must be selected
Settlement account exists Must be selected
Cross Office Must be selected
Processing Tab
FIN copy service TGT
Communication preferences Wait for confirmation
2.3.1.5.3 Cut-off Times Profile
The Cut-off Times profile defines the latest time for transactions to be processed for TARGET2 MOP.
The TARGET2 calendar is required for the TARGET2 Clearing. The calendar sets the holidays and
weekends which are non-working days in Singapore.
The TARGET2 Calendar profile for the office is defined under System Setup > Geographic Settings >
Calendars.
This is the suggested setup with specific attributes that need to be defined in the Cut-off profile for
TARGET2 Clearing.
Field TARGET2 for
Customer Payments TARGET2 for Bank to
Bank Payments Comment
Cut-off name TARGET2_cust TARGET2_B2B
Cut-off type Clearing Clearing
Time zone GMT GMT Time zone for aligning cut-off
times
Description TARGET2 Clearing
Cut-off for customer
payments
TARGET2 Clearing
Cut-off for bank to
bank payments
Cut-off time 17:00 18:00
2.3.1.5.4 Membership Profile
The TARGET2 Membership profile defines whether the payment receiver and sender parties are
members of the clearing house.
These are the specific attributes that need to be defined in the Membership profile for TARGET2 Clearing
for the Singapore office.
Field Value for TARGET2 Comment
MOP TARGET2
Type of
Membership Full member for TARGET2
participants (or associates) This membership record needs to be setup
only for the direct participant
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 14
2.3.1.5.5 Identifiers Profile
The TARGET2 Identifiers profile is used to set up and view the party identifiers and settlement account
information for the MOP.
These are the specific attributes that need to be defined in the Identifiers profile for TARGET2 Clearing.
Field Value for TARGET2 Comment
MOP TARGET2
Identifier Bank BIC
Settlement
account Office, Account number, Currency In a multi office setup the identifier is setup
only for the direct participant office
2.3.1.5.6 User Codes
User codes for liquidity priority codes should be defined for T2 payments tag 113 (for example, BI, NN,
UP).
Field Value for TARGET2 Comment
Type LIQ_PRTY A retrofit is required for versions that do not
have this type, in order to setup field 113 for
T2
Code Example: UP, NN
Description Example: Target2 – Banking
priority urgent
2.3.1.6 Rules
These are examples of user-defined rules.
2.3.1.6.1 MOP Selection
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
TARG
ET21 N/A TARGET2
MOP
selection rule
Local
office [Sttl
m
Ccy]
= EUR SET
MOP
Profile
TARGET
2
AND [Msg
tp] IN SWIFT_1
03,
SWIFT_2
02
AND [Cdtr
Agt
ctry]
= DE, FR,
IT, ….
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 15
2.3.1.6.2 Clearing Cut Off
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
TARG
ET2_
Cust
N/A TARGET2
cut off
selection rule
for MT103
Local
office [Cdt
MOP
]
= TARGET2 SET
TARGET
2_cust
cut off
(17:00)
AND [Msg
tp] = SWIFT_1
03
TARG
ET2_
B2B
N/A TARGET2
cut off
selection rule
for MT202
Local
office [Cdt
MOP
]
= TARGET2 SET
TARGET
2_B2B
cut off
(18:00)
AND [Msg
tp] = SWIFT_2
02
2.3.1.6.3 Liquidity Priority Selection Rules
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
TGT_
PRIO
RITY_
1
N/A Set NYNN
priority for all
TGT
payments
Local
office [Cdt
MOP
]
= TARGET2 NN
2.3.1.7 Target2 Directory Upload
The upload task can be executed from the GPP user interface using the option TARGET2 Upload. It uses
the system parameter T2DIRFPATH to locate the TARGET2 Directory file on the server.
The user has two modes of directory upload; Partial and Full. The user can browse for a required
TARGET2 file and click Execute to load it in the system. Based on file naming convention, different files
are shown to the user for different upload types (Full or Partial).
2.3.1.7.1 Target2 Directory Processing
The following validations are performed on an individual record in the file before updating the data in the
Membership table.
• Record is skipped if any of its mandatory field is blank.
• Record is skipped if the field format does not have a value specified in format standards (for example,
Modification Flag is not A, M, U or D).
• Record is skipped if any of the field’s length is more than specified in the format.
• Record is skipped if its Valid from Date is greater than Valid to Date.
• Record is skipped if Valid from Date of new record is earlier than the Valid from Date of existing
record and the date ranges of these two records overlaps.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 16
2.3.2 EURO1
2.3.2.1 Overview
EURO1 is the only private sector large-value payment system for single same-day euro transactions at a
Pan-European level. The EURO1 system processes transactions of high priority and urgency, and
primarily of large amount, both at a domestic and at a cross-border level.
The service provides a unique RTGS-equivalent multilateral net settlement arrangement, duly approved
by the European Central Bank (ECB).
Additional Information related to EURO1:
Value
FIN Copy service identifier code The User Header, Block 3, of payment messages to be
processed by EURO1, must contain Field 103 set to EBA to
denote processing for processing through the EURO1 Clearing
System.
Service Type Y-Copy
Currency code EUR
Operating hours of EURO1 Settlement Days (also known as Clearing Days) are normally
Monday to Friday each week. The service is processed euro
payments on all days when the TARGET2 system is open to
settle euro payments.
The maximum forward Settlement Day is set to 5 future
Settlement Days (not including the current Settlement Day)
within a maximum of 14 calendar days. Payments sent ahead of
Value Date are validated and stored for future processing.
Cut-off time 16:00
Special Processing This field can be used to identify a prioritized payment. In this
field, four characters are available. If the first character is H or
U, or if the third and fourth characters are UP then this payment
is identified as a prioritized payment.
There is no distinction between the payments marked with H or
U or UP.
In addition, a bank may request that an MT012 Sender
Notification is sent back to them on an individual payment basis.
To receive this, the character 2 of field 113 in the user header in
the sent payment message must be set to Y (any other identifier
is ignored by the central server).
2.3.2.2 Inward/Outward Processing
EURO1 can be setup in GPP as a EUR Method of Payment. A respective MOP selection rule needs to be
created to define the scenarios in which EURO1 is selected.
SWIFT standard validations are applied on outgoing payments to EURO1.
Outgoing payments that missed EURO1 cut-off time and no other relevant MOPs are available, are
stored in the Scheduled queue and processed on the next business day.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 17
2.3.2.2.1 Inward Payments from EURO1
1. A payment received from EURO1 has these values:
a. Sender = EURO1 member BIC
b. Fin copy service in field 103 block 3 = EBA
2. When GPP identifies the values in step 1 the Debit MOP is set to EURO1.
3. Debit MOP validation is performed as per MOP attributes.
4. Debit account is set to EURO1 settlement account.
2.3.2.2.2 Outward Payments to EURO1
To select EURO1 as the credit MOP, GPP performs MOP validation. For example:
• Settlement currency (SWIFT tag 32A) is EUR
• Settlement date (SWIFT tag 32A) is within the range available for EURO1
• As membership validation is required for EURO1 (setup in the MOP profile), GPP checks that the first
in credit chain is a member or associate member of EURO1
o If validation is successful and MOP EURO1 is selected by the rule, then GPP sends the payment
with the following enrichments:
Field 103 in block 3 is set to EBA
Local office BIC (defined as the MOP identifier) is defined as the sender in block 1
2.3.2.3 Flow Processes with EURO1
The flow process for all Y-Copy RTGS is the same and supported by GPP. As Target2 is a Y-Copy
service type, see Y-Copy RTGS Flow Processes for a description of the process.
2.3.2.4 Business Setup
Setup Additional Information
System Parameters N/A
Profiles MOP, Cut Off Times, Membership, Identifiers. Profiles
Rules
MOP selection, Clearing Cut-off
Rules
Permissions N/A
Tasks N/A
Queues N/A
2.3.2.4.1 Profiles
These are the details of the required setup in GPP profiles for the Clearing Certification.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
2.3.2.4.1.1 Method of Payment Profile - Single Office Setup
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 18
To successfully identify the local office and the debit MOP, when an incoming message is received from
EURO1, the local office’s BIC (provided in Block 1 of the incoming payment) needs to be set as a valid
identifier for this MOP in the MOP profile.
These are the specific attributes that need to be defined in the Method of Payment profile for EURO1
Clearing.
Field Value for EURO1 Comment
Name EURO1
Calendar Relevant calendar or no
value
MOP Business
Date Current business day for
the MOP The business date can be changed manually or by
an end-of-day task that advances the MOP business
date to the next valid business date for the MOP.
Currency EUR
Settlement
accounting EURO1 settlement
account
Membership
Required Must be selected
Membership type MOP
Send outgoing
message Must be selected
Settlement
account exists Must be selected
Processing Tab
FIN copy service EBA
Communication
preferences Wait for confirmation
2.3.2.4.1.2 Method of Payment Profile - Multi Office Setup
For multi office setup, the list of MOPs in the MOP selection of the indirect Office includes MOP EURO1
as the Multi Office MOP. When this MOP is selected, a payment is sent to EURO1 where the Sender is
the direct participant.
Field Value for Direct Participant Office
Name EURO1
Calendar Relevant calendar or no value
MOP Business Date Current business day for the MOP
Currency
EUR
Settlement accounting EURO1 settlement account in office Y
Membership Required Must be selected
Membership type MOP
Send outgoing message Must be selected
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 19
Field Value for Direct Participant Office
Settlement account exists Must be selected
Cross Office Must be selected
Processing Tab
FIN copy service EBA
Communication preferences Wait for confirmation
2.3.2.4.1.3 Cut-off Times Profile
The Cut-off Times profile defines the latest time for transactions to be processed for EURO1 MOP.
The EURO1 calendar is required for the EURO1 Clearing. The calendar sets the holidays and weekends
which are non-working days.
The EURO1 Calendar profile for the office is defined under System Setup > Geographic Settings >
Calendars.
This is the suggested setup with specific attributes that need to be defined in the Cut-off profile for
EURO1 Clearing.
Field EURO1 for
Customer Payments EURO1 for Bank to
Bank Payments Comment
Cut-off name EURO1_cust EURO1_B2B
Cut-off type Clearing Clearing
Time zone GMT GMT Time zone for aligning cut-off
times
Description EURO1 Clearing Cut-
off for customer
payments
EURO1 Clearing
Cut-off for bank to
bank payments
Cut-off time 16:00 16:00
2.3.2.4.1.4 Membership Profile
The EURO1 Membership profile defines whether the payment receiver and sender parties are members
of the clearing house.
These are the specific attributes that need to be defined in the Membership profile for EURO1 Clearing.
Field Value for EURO1 Comment
MOP EURO1
Type of
Membership Full member for EURO1
participants (or associates)
2.3.2.4.1.5 Identifiers Profile
The EURO1 Identifiers profile is used to set up and view the party identifiers and settlement account
information for the MOP.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 20
These are the specific attributes that need to be defined in the Identifiers profile for EURO1 Clearing.
Field Value for EURO1 Comment
MOP EURO1
Identifier Bank BIC
Settlement
account Office, Account number,
Currency In a multi-office setup, the identifier is defined only
for the direct participant office
2.3.2.4.1.6 User Codes
User codes for liquidity priority codes should be defined for EURO1 payments tag 113 (for example, 25,
40, 42, 45).
Field Value for EURO1 Comment
Type LIQ_PRTY A retrofit is required for versions that do not have this type,
in order to setup field 113 for EURO1.
Code Example: UP
Description Example: EURO1 –
Banking priority
urgent
2.3.2.4.2 Rules
These are examples of user defined rules.
2.3.2.4.2.1 MOP Selection
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
EURO
1_1 N/A EURO1 MOP
selection rule Local
office [Sttl
m
Ccy]
= EUR SET
MOP
Profile
EURO1
AND [Msg
tp] IN SWIFT_1
03,
SWIFT_2
02
AND [Cdtr
Agt
ctry]
= DE, FR,
IT, ….
2.3.2.4.2.2 Clearing Cut Off
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 21
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
EURO
1 N/A EURO1 cut
off selection
rule
Local
office [Cdt
MOP
]
= EURO1 SET
EURO1
cut off
(16:00)
2.3.2.4.2.3 Liquidity Priority Selection Rules
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
TGT_
PRIO
RITY_
1
N/A Set NYNN
priority for all
TGT
payments
Local
office [Cdt
MOP
]
= EURO1 NN
2.3.3 UK CHAPS
2.3.3.1 Overview
The Clearing House Automated Payment System (CHAPS) is a UK payments scheme which processes
the same day sterling fund transfers. CHAPS is recognized by HM Treasury as an inter-bank payment
system and is overseen by the Bank of England. Settlement of payments, within the CHAPS system, is
final and irrevocable, and is catered for in their Rules which all participants of CHAPS must adhere to.
In December 2005 the Bank of England decided that it was not viable for the UK to join TARGET2. As a
result of this decision CHAPS Euro was decommissioned in May 2008.
CHAPS provides a payment system between its Members, settling in real time across settlement
accounts at the Bank of England. The key components of the system are:
• A payment messaging network (SWIFT FIN Copy) connecting the Members of the system.
• SWIFT interfaces, known as CBTs (Computer Based Terminals), located within Members’ systems to
connect to the network and process messages to and from Member payment systems. The RTGS
system also has a CBT, known as the CHAPS Central Bank Interface, to connect to the network to
enable settlement to occur.
• Settlement accounts are denominated in all supported currencies held within the Bank of England’s
RTGS Processor and the supporting collateral arrangements.
• An Enquiry Link facility provided by the Bank of England.
• CHAPS Payments exchanged over the SWIFT network are sometimes referred to as clean
payments, so as to distinguish them from payments related to securities settlement (DVP).
• In the RTGS Processor the payment settlement account is the prime account in the Minimum Balance
Group (MBG) across which CHAPS and non-CHAPS payments (such as BACS and Cheque and
Credit clearings, note transactions) are applied.
Additional information related to CHAPS.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 22
Value
FIN Copy service identifier code STG
Service Type Y-Copy
Currency code GBP
Operating hours of CHAPS MT103: 06:00 - 16:05
MT202: 06:00 - 16:20
Cut-off time MT103: 16:00
MT202: 16:20
2.3.3.1.1 CHAPS Sterling Payments
CHAPS Clearing House operates for payments as follows:
1. Payments are sent from one Member to another.
2. The payments are stored within FIN Copy pending settlement confirmation by the Bank of England.
3. The full payment is sent to the Bank of England for settlement.
4. Once the payment is settled at the Bank of England, a confirmation is returned and the payment is
forwarded to the receiving Member. Finality is achieved when the payment is settled.
5. The receiving Member processes the payment as required.
The FIN Copy service provides the transport network for the system and the message handling
functionality required to convey settlement requests to (and receive settlement confirmations from) the
Bank of England (RTGS).
2.3.3.1.2 Business Day Processing Cycle
The business day follows the following processing cycle:
1. RTGS opens for business
2. Intra-day repurchase transactions and any other pre-business day transactions are initiated between
the Bank of England and CHAPS Members. These provide liquidity for the sterling service for those
CHAPS Members with sterling settlement accounts. Automated transfers are also made from the
settlement accounts used for payments to settlement accounts used for DVP.
3. CHAPS opens for business.
4. Intra-day payments are made.
5. CHAPS closes for normal payments.
6. Balancing payments are made between Members.
7. CHAPS closes for business.
8. Intra-day repurchase transactions are terminated.
9. Close of Day.
Key times in Chaps:
• Start of Business: CHAPS opens for payments at 06:00 on each CHAPS Business Day. Participants
must be open by 08:00 and must be sending by 10:00.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 23
• Close of Business:
o The latest time a customer MT103 payment should enter the SWIFT Network is 16:00. This allows
for a five-minute period to meet the SWIFT Service Level processing time. The last time for receipt
by the real-time gross settlement (RTGS) system of inward MT103 payments for same day value
is 16:05. Participants must, at 16:05, cancel any customer payments for which settlement
requests are on the funds queue.
o MT202 payments, which may be made between 16:00 and 16:20, are Settlement Period
Payments, unless bi-laterally agreed. In addition, a Participant can send a total of 9 payments, up
to a value of £1million each, to other Participants. The last time for receipt by the RTGS system of
inward MT202 payments for same day value is 16:20.
2.3.3.1.3 Bank Identifier Codes (BICs)
The preferred branch identification method used in CHAPS for payments is BICs, and this is the only
option available for payments sent to RT. UK Sort Codes are supported in most payment message
formats if no BIC is available.
2.3.3.2 Inward/Outward Processing
2.3.3.2.1 Inward Payments from CHAPS
GPP processes incoming MT103 and MT202 payments from CHAPS as follows:
1. A payment received from CHAPS has these values:
o Sender = CHAPS member BIC
o Fin copy service in field 103 block 3 = STG
2. When GPP identifies the values in step 1 the Debit MOP is set to CHAPS.
3. Debit MOP validation is performed as per MOP attributes.
4. Debit account is set to CHAPS settlement account.
2.3.3.2.2 Outward Payments to CHAPS
In order for GPP to process the outgoing payments according to CHAPS requirements, the credit Method
of Payment (MOP) is set as CHAPS.
• When CHAPS is selected as the credit MOP, GPP performs MOP validation. For example:
o Settlement currency (SWIFT tag 32A) is GBP
o Settlement date (SWIFT tag 32A) is within the range available for CHAPS. If the payment includes
a future value date, GPP warehouses the payment until the value date. On the value date, the
payment is processed and released to CHAPS. For more information, see GPP Business Guide
Value Date and Cut-off Time.
o As membership validation is required for CHAPS (setup in the MOP profile), GPP checks that the
first in credit chain is a member or associate member of CHAPS
• Receipt of payment confirmation: A bank can define whether to complete the payment processing
before confirmation is received from CHAPS. When confirmation from CHAPS is required, the bank
must also define that confirmation from SWIFT is required.
o If validation is successful and MOP CHAPS is selected by the rule, GPP sends the payment with
the following enrichments:
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 24
Field 103 in block 3 is set to STG
Local office BIC is defined as the sender in block 1
2.3.3.3 Flow Processes with CHAPS
The flow process for all Y-Copy RTGS is the same and supported by GPP. As CHAPS is a Y-Copy
service type, see Y-Copy RTGS Flow Processes for a description of the process.
2.3.3.4 Business Setup
Setup Additional Information
System Parameters N/A
Profiles MOP, Cut Off Times, Membership, Identifiers,
User Codes
Profiles
Rules MOP selection, Clearing Cut-off, Liquidity
Priority Selection Rules Rules
Permissions
N/A
Tasks N/A
Queues N/A
2.3.3.4.1 Profiles
These are the details of the required setup in GPP profiles for the Clearing Certification.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
2.3.3.4.1.1 Method of Payment Profile - Single Office Setup
To successfully identify the local office and the debit MOP, when an incoming message is received from
CHAPS, local office’s BIC (provided in Block 1 of the incoming payment) needs to be set as a valid
identifier for this MOP In the MOP profile.
These are the specific attributes that need to be defined in the Method of Payment profile for CHAPS.
Field Value for CHAPS Comment
Name CHAPS
Calendar Relevant calendar or
no value
MOP Business Date Current business day
for the MOP The business date can be changed manually or by
an end-of-day task that advances the MOP business
date to the next valid business date for the MOP.
Currency GBP
Settlement
accounting CHAPS settlement
account
Membership
Required Must be selected
Membership type MOP
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 25
Field Value for CHAPS Comment
Send outgoing
message Must be selected
Settlement account
exists Must be selected
Processing Tab
FIN copy service
STG
Communication
preferences Wait for confirmation
2.3.3.4.1.2 Method of Payment Profile - Multi Office Setup
For multi office setup the list of MOPs in the MOP selection of the indirect Office is included MOP EURO1
as the Multi Office MOP. When this MOP is selected, a payment is sent to EURO1 where the Sender is
the direct participant.
Field Value for office Y (direct participant)
Name CHAPS
Calendar Relevant calendar or no value
MOP Business Date Current business day for the MOP
Currency GBP
Settlement accounting CHAPS settlement account in office Y
Membership Required Must be selected
Membership type MOP
Send outgoing message
Must be selected
Settlement account exists Must be selected
Cross Office Must be selected
Processing Tab
FIN copy service STG
Communication preferences Wait for confirmation
2.3.3.4.1.3 Cut-off Times Profile
The Cut-off Times profile defines the latest time for transactions to be processed for CHAPS MOP.
The CHAPS calendar is required for the CHAPS Clearing. The calendar sets the holidays and weekends
which are non-working days.
The CHAPS Calendar profile for the office is defined under System Setup > Geographic Settings >
Calendars.
This is the suggested setup with specific attributes that need to be defined in the Cut-off profile for
CHAPS.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 26
Field CHAPS for Customer
Payment CHAPS for Bank to
Bank Payments Comment
Cut-off name CHAPS_cust CHAPS_B2B
Cut-off type
Clearing
Clearing
Time zone GMT GMT Time zone for aligning cut-off
times
Description CHAPS Clearing Cut-
off for customer
payments
CHAPS Clearing Cut-
off for bank to bank
payments
Cut-off time 16:00 16:20
2.3.3.4.1.4 Membership Profile
The CHAPS Membership profile defines whether the payment receiver and sender parties are members
of the clearing house.
These are the specific attributes that need to be defined in the Membership profile for CHAPS.
Field Value for CHAPS Comment
MOP CHAPS
Type of
Membership Full member for CHAPS participants (or
associates)
2.3.3.4.1.5 Identifiers Profile
The CHAPS Identifiers profile is used to set up and view the party identifiers and settlement account
information for the MOP.
These are the specific attributes that need to be defined in the Identifiers profile for CHAPS.
Field Value for CHAPS Comment
MOP CHAPS
Identifier Bank BIC
Settlement
account Office, Account number, Currency In a multi office setup the identifier is
defined only for the direct participant
office
2.3.3.4.1.6 User Codes
User codes for liquidity priority codes should be defined for CHAPS payments tag 113 (for example, 50,
35).
Field Value for CHAPS Comment
Type LIQ_PRTY
Code Example: UP
Description Example: CHAPS – Banking priority
urgent
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 27
2.3.3.4.2 Rules
These are examples of user defined rules.
2.3.3.4.2.1 MOP Selection
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
CHAP
S _1 N/A CHAPS MOP
selection rule Local
office [Sttl
m
Ccy]
= GBP SET MOP
Profile
CHAPS
AND [Msg
tp] IN SWIFT_1
03,
'SWIFT_2
02'
AND [Cdtr
Agt
ctry]
= GB
Clearing Cut Off
Rule
Name Rule
Sub
Type
Description Attache
d to AN
D/O
R
Field Operator Value/
Field/
Function
Action
CHAP
S_Cu
st
N/A CHAPS cut
off selection
rule for
MT103
Local
office [Cdt
MOP] = CHAPS SET
CHAP
S cut
off
(16:00)
AN
D [Msg tp] = SWIFT_103
CHAP
S_B2
B
N/A CHAPS cut
off selection
rule for
MT202
Local
office [Cdt
MOP] = CHAPS SET
CHAP
S cut
off
B2B
cut off
(16:20)
AN
D [Msg tp] = SWIFT_202
2.3.3.4.2.2 Liquidity Priority Selection Rules
Rule
Name Rule
Sub
Type
Description Attache
d to AN
D/O
R
Field Operator Value/
Field/
Function
Action
CHAP
S_PRI
ORIT
Y_35
N/A Set RR35
priority for all
CHAPS
payments
above 10M
Local
office [Cdt
MOP] = CHAPS RR35
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 28
Rule
Name Rule
Sub
Type
Description Attache
d to AN
D/O
R
Field Operator Value/
Field/
Function
Action
AN
D [Orgnl
sttlm
amt]
>= 10,000,000
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 29
2.4 Single Payment APAC Clearing
2.4.1 Australia - RITS PDS
2.4.1.1 Overview
Reserve Bank Information and Transfer System (RITS) is Australia’s interbank settlement system.
Settlement takes place across RITS on a real-time gross settlement (RTGS) and batch basis.
The Australian dollar leg of foreign exchange transactions, either AUD flows arising from CLS or
correspondent bank settlements and other large-value SWIFT transactions. These are made through the
HVCS (High Value Clearing System). The HVCS is also termed the SWIFT Payment Delivery System
(PDS).
Additional information related to RITS.
Value
FINCopy service identifier code
PDS
Service Type Y-Copy
Currency code AUD (Australian dollars)
Operating hours 09:15 until 17:15 Monday to Friday
Cut-off time SWIFT payments are cut-off 25 minutes prior to the end of the
Evening Settlement Session
2.4.1.1.1 RITS Business Hours
RITS is available to Members for settlement across Exchange Settlement Accounts on days when banks
generally are open for business in Sydney or Melbourne. RITS is closed on weekends and public
holidays.
Core Business Hours are 9:15 to 17:15, Monday to Friday for those Participating Members that are not
participating in the Evening Settlement Session, and 9:15 to 17:20/18:30/20:30 for those Participating
Members that are participating in the Evening Settlement Session.
2.4.1.1.2 Supported Message Types
GPP supports the following SWIFT message types for RITS PDS:
• MT103
• MT103+
• MT202
• MT202COV
• MT012
• MT019
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 30
2.4.1.2 Inward/Outward Processing
• Incoming RITS payments are received from RBA and processed in GPP.
• Outgoing payments are received in GPP from Teller and Internet Banking interfaces, processed and
sent to RBA. Outgoing payments that missed RITS cut-off time are moved to the Wait Release queue
and processed on the next business day.
2.4.1.2.1 Confirmation/Rejection Messages
Confirmation/rejection messages (MT012/MT019) are expected to be received for outgoing messages.
The payment waits for the message before proceeding to completion.
2.4.1.2.2 Reject/Return Messages
For an incoming payment which falls into one of the manual queues, GPP allows a user to select to
reject/return the payment. GPP automatically generates an outward R-message linked to the original
payment, and performs the following actions:
• Replace sender and receiver in block 1 and block 2
• Field 21 is mapped from field 20 of the original message
• Fields 50, 52, 53, 54, 56, 57, 59 and 70 remains the same as those of the original message
• Field 72 is indicated as /REJT or /RETN
The original message is sent to the Rejected or Returned queue.
2.4.1.2.3 Cancellation Messages
Cancellation messages (n92, n96) for PDS RTGS payments are sent via SWIFT MOP and follow the
standard Cancellation Flow.
2.4.1.2.4 Incoming Payments
Each Payment Delivery System (PDS) member has an RTGS BIC (PDS BIC). The PDS BIC is the Bank
published BIC, where the eighth letter is replaced with R.
For incoming payments where the sender is a RITS member with a PDS BIC:
1. GPP identifies the original MOP as RITS, based on FIN copy service.
2. GPP looks for the sender’s party. GPP tries to find a party where the BIC equals the sender BIC (as
PDS BICs are set as separate entities in the Parties profile, the search should be successful).
3. If field 52 is empty, the sender party BIC (if published), or name and address (if the BIC is not
published) is added to field 52 to identify the sender in onwards messages, based on the first party
profile found. This is achieved using Mapping out selection and mapping out rules.
2.4.1.2.5 Outgoing Payments
• If MOP is PDS, the PDS BIC (set in the Membership profile) of the first in credit chain is mapped to
the message head of an outward payment message as message receiving bank.
• The published BIC and corresponding BSB (Bank State Branch) remains in the outward message as
first in chain.
• PDS BIC is not used in block 4 of the payment message.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 31
• When an incoming payment from PDS, has RTGS BIC as original sender and requires generation of
an outgoing transaction (for example, request for charges) to be sent to SWIFT, the outgoing
transaction is sent to the SWIFT BIC and not the RTGS BIC.
• SWIFT Payments (MT103 and MT202) sent by banks, with any combination of alphanumeric
characters, provided to SWIFT standards field 20, should be unique for the bank within a 14 day
period; and should not start with RITS, AXCS or ACLR.
2.4.1.2.6 BSB Processing
BSB (Bank State Branch) codes are defined in the NCC (National Clearing Codes) profile. The BSB
number is a six digit numerical code used to identify an individual branch of a financial institution in
Australia. It consists of three parts in the format of XXY-ZZZ:
o The First two digits (XX) specify the parent financial institution
o Third digit (Y) specifies the state where the branch is located
o Fourth, fifth and sixth digits (ZZZ) specify the branch location
In order to increase STP and ensure that every Australian RTGS payment is sent with a valid BSB, the
following process is applied to incoming and outgoing messages.
• GPP searches for a BSB within the payment message.
o If the BSB is found, GPP validates the BSB. When a valid BSB is found GPP enriches the
message with the BSB from less structured formats (for example, F72) to first in Credit chain and
then continues to process the payment.
o If the BSB is not found or it is invalid, GPP sends the payment to Manual Repair.
• When repairing a BSB, for Australian RTGS payments a valid BSB code needs to be inserted in the
Party Identifier field of the first in credit chain proceeded by AU (AUNNNNNN). This is to allow the
receiving bank to identify the branch where the customer’s account is conducted.
For MT202 messages:
• When a valid BSB code, cannot be identified on a PDS MT202 message the bank can send the
payment to the receiving bank’s default BSB.
• If the payment is identified as a Treasury payment and there is a second default BSB for MT202
transactions, the Treasury BSB must be used.
For more information on NCC validations, see GPP Business Guide Parties Identification.
2.4.1.2.7 Membership Validation Using Metro/Country BIC level
PDS members are members at Bic-6 level. Therefore, the membership check can be defined either on
Metro (BIC-8) or country (BIC-6) level.
On the MOP profile when Check Main BIC in Membership is selected, the Membership check level is
available, with the default set to Metro. The user can change it to country, allowing the membership check
to be based on first 6 characters of the BIC.
The membership check is then performed using 8 or 6 characters of the BIC provided in the first in credit
chain based on the set up in the MOP profile.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 32
2.4.1.3 Flow
The flow process for all Y-Copy RTGS is the same and supported by GPP. As RITS is a Y-Copy service
type, see Y-Copy RTGS Flow Processes for a description of the process.
2.4.1.4 Business Setup
Setup Additional Information
System Parameters N/A
Profiles MOP, Cut Off Times, Membership, Identifiers,
National Clearing Codes, Parties Profiles
Rules MOP selection, Clearing Cut-off, Missed
Clearing Cut-off, Party Details Enrichment Rules
Permissions As per customer’s requirement
Tasks N/A
Queues N/A
2.4.1.4.1 Profiles
These are the details of the required setup in GPP profiles for the Clearing Certification.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
2.4.1.4.1.1 Method of Payment Profile
In order to successfully identify the local office and the debit MOP, when received an incoming payment
from PDS, local office PDS BIC (provided in block 1 of the incoming payment) should be set as a valid
identifier for this MOP.
These are the specific attributes that need to be defined in the Method of Payment profile for RITS
Clearing.
Field Value for AU RITS Comment
Name PDS
Description AU PDS Clearing MOP
(RITS)
Calendar PDS_AU If no calendar is assigned, the default calendar for
the office is used.
MOP Business Date Current business day
for the MOP
Value date extension 7 Payments with value dates between the latest
value date and the value date extension is
validated for the particular MOP and then sent to
the Schedule queue.
Currency AUD
Settlement accounting PDS settlement
account
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 33
Field Value for AU RITS Comment
Membership Required Must be selected
Membership type MOP
Send outgoing
message Must be selected
Settlement account
exists
Must be selected
Processing Tab
FIN copy service PDS
Communication
preferences Wait for confirmation
2.4.1.4.1.2 Cut-off Times Profile
The Cut-off Times profile defines the latest time for transactions to be processed for PDS MOP.
If cut-off dates are subject to change each year, there are two additional options to implement the
different cut-off times:
• Define one cut-off profile and change manually the final cut-off in the profile based on the RBA
notification.
• For a single cut-off profile, define each year a cut-off exception for the period of the summer/winter
cut-off schedule.
The following settings is defined for the PDS Cut-off Times Profiles.
2.4.1.4.1.3 PDS Winter Cut-off
Field Value for AU RITS Comment
Department TBD
Office AU1
Cut-off name PDS_WINT
Cut-off type Clearing
Time zone AEST Australia Eastern Standard Time (GMT+10)
Description PDS AU Winter
Clearing Cut-off
Interim cut-off time 16:30 From this time until the final cut-off, only MT202 is
accepted
Final cut-off time 18:05
2.4.1.4.1.3.1 PDS Summer Cut-off
Label in Profile Value for AU RITS Comment
Department TBD
Office
AU1
Cut-off name PDS_SUMM
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 34
Label in Profile Value for AU RITS Comment
Cut-off type Clearing
Time zone AEST Australia Eastern Standard Time (GMT+10)
Description PDS AU Summer
Clearing Cut-off
Interim cut-off time 16:30 From this time until the final cut-off, only MT202 is
accepted
Final cut-off time 20:05
2.4.1.4.1.4 Memberships
The PDS Membership profile defines whether the payment receiver and sender parties are members of
the clearing house.
Each PDS member has a RTGS BIC (PDS BIC). The PDS BIC is the Bank published BIC, where the
eighth letter is replaced with R.
These are the specific attributes that need to be defined in the Membership profile for AU RITS Clearing.
Field Value for AU RITS Comment
MOP PDS
Type of Membership Full member for AU
RITS participants
(or associates)
PDS BICs are set as full members of RITS.
2.4.1.4.1.5 Identifiers
PDS Identifier is used to set up and view the party identifiers and settlement account information for the
MOP.
These are the specific attributes that need to be defined in the Identifiers profile for AU RITS Clearing.
Label in Profile Value for AU RITS Comment
MOP PDS
Identifier <PDS BIC>
Settlement Account:
Office AU1
2.4.1.4.1.6 National Clearing Codes (NCC)
The National Clearing Codes (NCC) profile is used to manage the list of BSB Codes used by banks in
AU. The NCC profile supports two indicators for the BSB:
• Default NCC
• Treasury NCC
These are the specific attributes that need to be defined in the NCC profile for AU RITS Clearing.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 35
Label in Profile Value for AU RITS Comment
Clearing system ID AUBSB Australia – AUBSB
Member ID BSB Code
2.4.1.4.1.7 Parties Profile
The Parties profile maintains customer data.
For AU RITS Clearing, a new party needs to be defined with the PDS BIC.
Label in Profile Value for AU RITS Comment
Unpublished BIC Checkbox Selected For PDS BICs that are separate entities
2.4.1.4.2 Rules
2.4.1.4.2.1 MOP Selection
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Oper
ator Value/
Field/
Function
Action
PDS_
MOP N/A PDS MOP
Selection
Rule
AU1 [Sttlm
Ccy] = AUD SET
MOP
Profile
AU1^P
DS
AND [Msg
tp] IN SWIFT_1
03,
'SWIFT_2
02'
AND [Cdtr
ctry] = AU
2.4.1.4.2.2 Clearing Cut-off
In the following example, winter time is set to 5.10.2014-4.4.2015, any create date in this period returns
TRUE.
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Oper
ator Value/
Field/
Function
WINT
ER_S
CHED
N/A Base
condition for
winter cut-off
period
AU1 ( DATE_EXTRAC
T(YEAR,[P_CRE
ATE_DT])
= 2014
and (
( DATE_EXTRAC
T(DAY,[P_CREA
TE_DT]
>= 5 )
and DATE_EXTRAC
T(MONTH,[P_C
REATE_DT])
= 10 )
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 36
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Oper
ator Value/
Field/
Function
or ( DATE_EXTRAC
T(MONTH,[P_C
REATE_DT])
> 10 )
)
or DATE_EXTRAC
T(YEAR,[P_CRE
ATE_DT]
= 2015
and ( DATE_EXTRAC
T(DAY,[P_CREA
TE_DT]
<= 4
and DATE_EXTRAC
T(MONTH,[P_C
REATE_DT]
= 4
or DATE_EXTRAC
T(MONTH,[P_C
REATE_DT
< 4 )
)
WINT
_CUT
OFF
N/A PDS
Clearing cut-
off - winter
AU1 [Cdt MOP] = PDS
AND BASE_CONDITI
ON(WINTER_SC
HED)
= TRUE
SUM
M_CU
TOFF
N/A PDS
Clearing cut-
off - summer
AU1 [Cdt MOP] = PDS
AND BASE_CONDITI
ON(WINTER_SC
HED)
= FALSE
2.4.1.4.2.3 Missed Clearing Cut-off
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Oper
ator Value/Fiel
d/Functio
n
Action
PDS_
202_C
UTOF
F
Allow
treasury
payments
during
interim cut-
off
AU1 [Cdt
MOP] = PDS
AND [Msg
tp] = SW IFT_2
02
2.4.1.4.2.4 Party Details Enrichment
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Oper
ator Value/Fiel
d/Functio
n
Action
ENRI
CHDE
FAUL
TNCC
Party
detail
s
enric
Enrich
default NCC
if BIC exist
AU1, AU2 [Msg
tp] in SW IFT_1
03,
SWIFT_2
02
SET
party
type
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 37
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Oper
ator Value/Fiel
d/Functio
n
Action
hme
nt
and NCC
doesn't exist AND [First
in cdt
chain
BIC]
Is not Empty
FIRSTI
NCR
...
usage
DEFA
ULT_N
CC
AND [First
in cdt
chain
NCC]
is Empty
AND [Cdt
MOP] = PDS
ENRI
CHTR
EASU
RYNC
C
Party
detail
s
enric
hme
nt
Enrich
Treasury
NCC if BIC
exist and
NCC doesn't
exist and
BIC6 of
F57&F58 or
F56&F58 are
equal
AU1, AU2 [Msg
tp] = SWIFT_2
02 SET
party
type
FIRSTI
NCR
...
usage
TREAS
URY_
NCC
AND [First
in cdt
chain
BIC]
Is not Empty
AND [First
in cdt
chain
NCC]
Is Empty
AND ( SUBS
TRIN
G([Cd
tr
BIC],0
,6)
= SUBSTRI
NG([Cdtr
agt
BIC],0,6)
OR SUBS
TRIN
G([Cd
tr
BIC],0
,6)
= SUBSTRI
NG([Intrm
y agt
BIC],0,6)
)
AND [Cdt
MOP] = PDS
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 38
2.4.2 Australia - RITS Austraclear
2.4.2.1 Overview
Austraclear is an electronic depository and settlement system for transferring ownership of financial
securities (such as commonwealth government and semi-government securities, and private sector
securities) between banks and financial institutions.
Austraclear Reserve Bank Information and Transfer (RITS) is Australia's high-value payments system,
which is used to settle payment obligations on a real-time gross settlement (RTGS) basis.
Exchange Settlement Accounts (ESA) are accounts held with Australia’s central bank, the RBA (Reserve
Bank of Australia), for the settlement of payment obligations to each other.
After GPP matches a transaction, an interbank settlement request is sent to RITS for settlement. Once
the payment is settled across ESAs, RITS notifies Austraclear, which then settles the transaction.
Additional information related to RITS:
Value
FINCopy service identifier code SWIFT FIN Copy service
Service Type Y-Copy
Currency code AUD (Australian dollars)
Operating hours 09:15 until 17:15 Monday to Friday
2.4.2.1.1 RITS Business Hours
Hours Description
07:30-08:45 Morning Settlement Session
08:45 to 9:15 Morning Processing
09:15 to 16:30 Daily Settlement Session
16:30 to 17:15 Settlement Close Session
17:15 to 17:20
Interim Session
17:20 to 22:00 Evening Settlement Session
22:00 to 22:30 Reports Session
22:30 to 07:30 Overnight Enquiry Session (the following RITS business day)
2.4.2.1.2 Supported Message Types
GPP supports SWIFT message type Proprietary Message (MT198) for Austraclear RITS, with the following
message sub types:
• SMT027 – Inward direct debit single payment
• SMT028 – Inward direct debit single payment
• SMT036 – Inward direct debit single payment
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 39
• SMT037 – Inward credit transfer single payment
• SMT038 – Inward direct debit single payment
2.4.2.1.3 RITS Payment Flow
1. Two Austraclear registered corporates do money
market deal WPAC corporate buys securities, therefore
pays
2. Deal approved by both parties
3. Details sent to
RI TS to arra nge
payment
4. Pre Settlement Advice: RITS sends MT198 -027/028
to debit bank for approval. RITS holds payment with
Cr edit st atus Deferred (‘D ’) until approved (‘A’).
6. Change ESA and/or credit status request: When
approved, bank sends MT198-007/031 to RBA to
change status from ‘D’ to ‘A’ and make payment.
7. RITS responds with MT198-008/032 confirm
payment status change accepted
8. Post Settlement Advice: RITS sends M T198-036 to
say payment made
Note, could get SMT036 without SMT027/028. Would
then process accounting off SMT036
10. RITS advises
Austraclear that
payment done so
securities can be
moved
GPP
(Buyer Bank)SWIFT RBA RITS
RTGS
Austraclear
Party 1 -
Buyer (Debit)
Party 2 -
Seller (Credit )
8
6
4
7
8
6
4
7
13
3
5
1 2
SWIFT GPP
(Seller Bank)
8 8
12. Bank
credits the
seller
12
8. Post Settlement Advice: RITS sends M T198-037 to
confirm payment made
DD HV flow
10 10
9 9
Termination
flow
11
Cancellation
flow CT HV flow
10. Unsettled Tx EOD Advice: RITS sends MT198-038 to
notify the paying bank that there are tra nsactions
which remain unsettled at the end of the Settlement
session.
5. Bank performs Credit Check and posting for debit
customer
9. In case of M T198-036 tha t w as ma tched to SMT027/
028, SMT036 will perform termination flow and
process to complete.
In cas e of M T198-036 that was unmatched to SMT027/
028, the payment will perform DD HV flow (Credit
check and debit customer.
11. An unsettled Tx EOD advice was received therefor
cancellation flow should be perform on the original
MT198-027/028
2.4.2.2 Inward Processing
2.4.2.2.1 Purchase of Securities (Buyer Bank)
2.4.2.2.1.1 Pre-Settlement Debit (MT198-027/028)
When a bank customer (or a bank) buys a security in Austraclear, the paying bank’s ESA account is
debited to settle the Austraclear transaction.
A bank’s ESA can be debited directly by the Reserve Bank, or, the Reserve Bank can request the bank to
update the credit status and thereby authorize the Reserve bank to debit the bank’s ESA.
The Reserve Bank requires bank’s approval to debit their ESA; this approval is agreed upon in advance
and is usually pre-determined. Immediately debiting the ESA involves a credit risk on behalf of the bank,
therefore if the underlying Austraclear transaction was initiated by a bank’s customer (instead of the bank
itself), then bank approval is required prior to debiting the ESA.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 40
Purchase of Securities (Buyer Bank) - Pre Settlement MT198-027/028
Reserve Bank GPP Back Office Systems
Phase
Change Status Response
MT198 – 008/032
Austraclear Paym ent
Initiation
Destinatio
n Sid e
Processing
Dr/Cr
MOP
Selection
Paymen t
Execu tio n
(Fees, FX,
S top Fl ag s)
Bal ance Check
Wa it BI
Complet
e
(MT198-
027/028)
Austraclear
CDB
Core Banking
Core Banking
Pre settlement ad vice
MT198 – 027/028
Acco unt Vali dation
BI R equest
Acco unti ng
Wait
Post ing
BI R esponse
Post ing/Adv ice R equest
Post ing Response
Post Settlemen t advice – Debi t
MT198 - 036
Post Settlemen t
adv ice MT198-
036 flo w
No
Yes
M at ched to an
exi sting SM T036?
Yes
Generate
transaction
Wait
Pos t avd
Change Status Request
MT198 – 007/031
Liq uid ity
Up da te
Interbank
I ntr ab an k
No
Interbank or
I ntr ab an k?
M at c he d?
Post Settlemen t
adv ice MT198-
036 flo w
Yes
Matched with an
exi sting
MT210RVR?
Yes
MT210RV
R in
Complete
SMT027
in
Complete
Source
Side
processing
Acco unt Vali dation
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 41
Details of the flow:
When the bank receives a Pre-Settlement Advice MT198-027 or MT198-028, GPP invokes the single
payment processing flow to perform funds availability for the debit customer.
1. Payment Initiation:
o GPP parses the message (MT198-027/028) and attempts to match the message to a previously
received MT198-036.
2. Duplicate Message: GPP checks for duplicated Pre-Settlement Advice MT198-027 or MT198-028
messages. These are messages with the same message type and values displayed in Field 20 and
Field 21.
o If a duplicate message is found:
And a matching (to MT198-036) message is found, the MT198-027/028 routes to Rejected
queue.
And a matching (to MT198-036) is not found, the original MT MT198-027/028 routes to
DUPEX.
3. Party Processing: The customer’s account to be debited is in Field 25 of the MT198-027/028. GPP
performs debit account derivation and Account Lookup validation based on the account sent in Field
25 of the received message.
Note: If an account is not found in the GPP repository, GPP interacts with other bank systems via the
Account Lookup interface, which provides the relevant credit customer details.
o If an account exists in GPP, GPP loads and validates the account.
o If an account does not exist in GPP, GPP tries Account Lookup.
If an account is found, GPP continues to process the message.
If an account is not found, the message routes to Repair queue.
4. Balance Check: GPP performs Balance Inquiry on the customer’s account derived from Field 25 of
the received message.
5. Accounting (First Leg): GPP initiates an account posting request for the customer’s account derived
from Field 25 of the received message, and routes the message to MP Wait queue, while it waits for a
posting response. The Second Leg (MT198-036) uses the Post Settlement Accounting flow.
6. After receiving a positive accounting Response, the message waits for the Post Settlement Advice in
the Wait Post Settlement Advice queue.
7. Post Settlement Advice (Debit) Completion:
o When a Post Settlement is received, and matched to the original Pre-Settlement Advice (MT198-
027/028), the original message routes to Complete status.
o When the Pre-Advice is parked in a Wait queue and post-advice is received and matched before
the pre-advice reaches final status (MT198-036 is received before the MT198-027/028, which
may already be in a (non-Wait Post advice) Wait queue):
If the pre-advice completes successfully (on completion of pre-advice), it routes automatically
to Complete status. GPP checks whether the pre-advice is matched to a post-advice:
- If it is matched successfully, GPP routes the pre-advice to Complete status.
- If it is not matched, GPP routes the pre-advice to Wait Confirmation status.
If the pre-advice fails processing, its status indicates a failure regardless of whether the pre-
advice is matched or not to a post-settlement advice. The user can either repair the failure
and re-submit the pre-advice, or fix it outside of GPP.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 42
2.4.2.2.1.2 Post Settlement Debit (MT198-036)
If the Paying Bank has chosen to be notified upon settlement for debit transactions, a Post-Settlement
Advice message is forwarded to the Paying Bank’s PPS (Proprietary Payments System).
The message also contains the Paying Client bank account number details that were passed in the
Settlement Request from Austraclear.
This advice is sent to the Paying Bank to advise the settlement of the debit transaction.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 43
Purchase of Securities (Buyer Bank) – Post Settlement MT198-036
Reserve Bank GPP Back Office Systems
Phase
Austraclear
Party
Processing
Dr/Cr
MOP
Selection
Payment
Execution
(Fees, FX,
Stop Flags)
Balance Check
Wait BI
Complet
e
(MT198-
036)
CDB
Core Banking
Core Banking
Post settlement advice
MT198 – 036
Account Validation
BI Request
Accounting (One
step accounting)
Wait
Posting
BI Response
Posting Request
Posting Response?
Matched to an
existing SMT027/
028?
Accounting (2
nd
leg accounting)
Liquidity
Update
Interbank
Intrabank
Interbank or
Intrabank?
MT198 -
036 in
Complet
e
Yes No
Liquidity
Update
Interbank
Intrabank
Interbank or
Intrabank?
Payment
Initiation
Party
Processing
Dr/Cr
MOP
Selection
Account Validation
Posting Response
Posting Request
Core Banking
Wait
Posting
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 44
Details of the flow:
When the bank’s ESA is debited, the Reserve Bank sends MT198-036 to confirm that the debit has been
posted to the account, for cases when the Post-Settlement Advice SMT036 received prior to the pre-
settlement advice.
1. Payment Initiation:
o GPP parses the message (MT198-036).
2. Duplicate Message: GPP checks for duplicated Post-Settlement Advice MT198-036 messages.
These are messages with the same message type and values displayed in Field 20 or Field 21.
o If a duplicate message is found:
And a matching (to MT198-027/028) message is found, the MT198-036 routes to Rejected
queue.
And a matching (to MT198-027/028) is not found, the original MT198-036 routes to DUPEX.
3. Party Processing: The customer’s account to be debited is in Field 25 of the MT198-036. GPP
performs debit account derivation and Account Lookup validation based on the account sent in Field
25 of the received message.
Note: If an account is not found in the GPP repository, GPP interacts with other bank systems via the
Account Lookup interface, which provides the relevant credit customer details.
o If an account is found in GPP, GPP loads and validates the account.
o If an account is not found in GPP, then GPP performs Account Lookup.
If an account is found, GPP continues to process the message.
If an account is not found in Account Lookup, the message routes to the Repair queue.
4. Balance Check: GPP performs Balance Inquiry on the customer’s account derived from Field 25 of
the received message (following the standard Balance inquiry process/Interface).
5. Accounting (One step accounting): GPP initiates an account posting request for the customer’s
account derived from Field 25 of the received message.
o GPP credits the settlement account (ESA).
o The transaction waits in MP Wait queue for the posting response (following the standard HV
posting interface process).
6. Completion: After receiving the posting response, the message routes to Complete status.
2.4.2.2.2 Sale of Securities (Seller Bank)
2.4.2.2.2.1 Post Settlement Credit (MT198-037)
When a customer of the bank (or the bank itself) enters a trade to sell a security in Austraclear, the bank’s
ESA account is credited to settle the Austraclear transaction.
The bank receives a post settlement credit (MT198-037):
• GPP debits the ESA account.
• GPP credits the account in Field 25.
• GPP performs Account Lookup, and then performs account posting.
Note: If an account is not found in the GPP repository, GPP interacts with other bank systems via the
Account Lookup interface, which provides the relevant credit customer details.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 45
Sell of Securities (Seller Bank) - Post Settlement MT198 - 037
Reserve Bank GPP Back Office Systems
Phase
Austraclear Paymen t
Initi ation
Part y
Processing
Dr/Cr
MOP
Selection
Paymen t
Execu tio n
(Fees, FX,
S top Fl ags )
Accounting
Wait
Posting
Complet
e
CDB
Core Banking
Post settlement advice - Cr edit
MT198 – 037
Account Validation
Post ing Request
Posting
Response
Liq uid ity
Up da te
Interbank
I ntr ab an k
Interbank or
I ntr ab an k?
Matched with an
exi sting
MT210RVR?
MT210R
VR i n
Service
Complete
Yes
No
Complianc e Co re Banking
Complianc e Req uest
Complianc e Response
Details of the flow:
When the bank’s ESA is credited, the Reserve Bank sends a post settlement credit (MT198-037) to the
Receiving Bank to advise the settlement of the credit transaction. GPP invokes the HV processing flow to
credit the receiving client RITS (Reserve Bank Information and Transfer) cash account.
1. Payment initiation:
o GPP identifies that the payment was received from Austraclear.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 46
o GPP identifies the settlement (ESA) account to debit.
2. Duplicated messages are regarded as messages with the same message type and values displayed
in Field 20 or Field 21. As a message already received previously in the system, such messages will
go to DUPEX.
3. Party Processing: The customer’s account to be credited displays in Field 25 of the MT198-027/029.
GPP performs credit account derivation and Account Lookup validation based on the account sent in
Field 25 of the received message.
Note: If an account is not found in the GPP repository, GPP interacts with other bank systems via the
Account Lookup interface, which provides the relevant credit customer details.
o If an account is found in GPP, GPP loads and validates the account.
o If an account is not found in GPP, then GPP attempts Account Lookup.
If an account is found in Account Lookup, the flow continues.
If an account is not found in Account Lookup, the payment routes to Repair status (following
the standard HV Account Lookup process).
4. Accounting (One-step accounting):
o GPP initiates an account posting request to debit the ESA account and credit the customer’s
account derived from Field 25 of the received message.
o The transaction waits in MP Wait queue for a posting response.
5. Completion: After receiving the posting response, the message routes to Complete status.
2.4.2.2.3 Exception Handling
2.4.2.2.3.1 Unsettled End of Day Advice (MT198-038)
At the end of the day, if a payment is not settled (for example, post settlement debit (MT198-036) was not
sent), RITS sends an Unsettled End-of-Day Advice (MT198-038) message.
The original payment (MT198-027/028) is in Pending status in GPP. The bank waits for a response from
the RBA. When received, the transaction is rejected.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 47
Sell of Securities (Seller Bank)
Reserve Bank GPP Back Office Systems
Phase
Refuse
Unsettled Advice MT198 - 038
Austraclear
Accounting
(Reversal) Core Banking
Unsettled advice
MT198 – 038
Posting Request
Posting
Response
Matched to an
existing SMT027/
028?
Service
Release
Queue
Yes
No
Liquidity
Update
Interbank
Intrabank
Interbank or
Intrabank?
Orig Message
SMT027/028
Cancellation
flow
Yes
Service
Wait
Orig
SMT027/
028 in
Approve
Cancel
Canceled
Approved?
Approved cancelation
Refuse
Orig
SMT027/
028 back to
previous
status
Orig
SMT038 in
Rejected
Approved
cancelation
Orig
SMT038 in
Complete
Service
Rejected
Queue
Details of the flow:
1. Unsettled Advice:
• GPP attempts to match the MT198-038 to MT198-027/028.
o If a match was not found, the message routes to Service Release queue for investigation.
o If a match was found:
GPP creates a link between these messages.
GPP routes the unsettled message to Service Wait.
GPP routes the message (SMT027\028) to Approve Cancel queue, where an authorized
user approves the cancellation of the original MT198-027/028 payment.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 48
2. Cancellation: An authorized user can refuse or approve the cancellation of the original MT198-
027/028 payment.
If the user refuses the cancellation:
- MT198-027 or MT198-028 routes back to previous status.
- MT198-038 processes to the Rejected status.
If the user approves the cancellation:
- MT198-038 processes to the Complete status.
- Cancellation flow is triggered on the original transaction (MT198-027/028).
3. Accounting: GPP initiates an Account Posting Request to reverse the entries performed as part of the
pre-settlement advice flow.
o The original SMT027/028 performs reverse accounting.
o The transaction waits in the MP Wait queue for the posting response (following the standard HV
posting interface process).
4. Completion: After receiving the posting response, the original SMT027/028 message routes to the
Cancel status.
o From the Service Release queue, the user can click Release to release the advice, which
indicates that the message was reviewed.
2.4.2.2.4 Accounting
This table shows the related accounting information for each flow and message sub type:
Flow Message
Sub
Type
Account-
ing Model Posting
Debit
account
Posting
Credit
account
Debit
Account Credit
Account Exception
Handling
Pre-
Settlement
Advice –
Debit
SMT027/
028 Two Step
Accounting
– Pre-
settlement
Customer
Account Suspense
Account Customer
Account ESA
Account Reverse
Posting in
case of
Cancellatio
n flow
Post
Settlement
Advice –
Debit
(Matched
to
SMT027/0
28)
SMT036 Two Step
Accounting
– Post
settlement
Suspense
Account ESA
Account Customer
Account ESA
Account N/A
Post
Settlement
Advice –
Debit
arriving
before Pre-
Settlement
advice
SMT036 One Step
Accounting
– Post
settlement
Customer
Account ESA
Account Customer
Account ESA
Account N/A
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 49
Flow Message
Sub
Type
Account-
ing Model Posting
Debit
account
Posting
Credit
account
Debit
Account Credit
Account Exception
Handling
Post
Settlement
Advice -
Credit
SMT037 One Step
Accounting
– Post
settlement
ESA
Account Customer
Account ESA
Account Custome
r Account N/A
Cancellatio
n Flow SMT027/
028 One Step
Accounting
–
Cancellatio
n flow
Suspense
Account Customer
Account Customer
Account ESA
Account N/A
SMT038 N/A N/A N/A N/A N/A N/A
2.4.2.3 Business Setup
Setup Additional Information
System Parameters N/A
Profiles Method of Payments, Identifier Profiles
Rules Posting Suspense Account Selection,
Suspense Account as Posting Credit Account,
Suspense Account as Posting Debit Account,
Compliance Validation
Rules
Permissions
N/A
Tasks N/A
Queues Wait ACK, Wait Post Settlement Advice, Wait
Confirmation, Wait MP, Service Release,
Approve Cancel
2.4.2.3.1 Profiles
2.4.2.3.1.1 Method of Payments Profile
For MT198 messages received from RITS RTGS, GPP uses the RITS MOP (Method of Payment).
These attributes must be defined in the MOP profile for RITS:
Field Value for RITS Comment
Name RITS
Description HV Australian RITS RTGS
Calendar
RTGS
MOP calendar name
Currency AUD Three-character ISO currency code for the MOP
Earliest value date 0 Number of days that the transaction can be sent
in advance to the clearing for the settlement date.
Latest value date 5 Number of days that the transaction must be sent
in advance to the clearing to meet the settlement
date.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 50
Field Value for RITS Comment
Send outgoing
message Not selected If selected, an outgoing payment message is
required for the MOP.
Multiple cycles No Select if MOP has multiple settlement cycles
during the day.
Settlement account
exists
Yes If selected, a settlement account has been
defined for the MOP.
Processing
FIN Copy Service SWIFT FIN service
Communication
preferences None No wait for ACK or Confirmation is required to
continue processing.
2.4.2.3.1.2 Identifier Profile
The Identifiers profile is used to set up and view the bank’s identifiers in RITS, and settlement account
information for the MOP.
These are the specific attributes that need to be defined in the Identifier profile for Austraclear RITS.
Field Value for RITS
Office The bank’s office
MOP RITS
Identifier
BIC used by RITS to identify the bank
Settlement Account Settlement Account number of the bank’s office
2.4.2.3.2 Rules
2.4.2.3.2.1 Posting Suspense Account Selection Rule – 207
The Posting Suspense Account Selection Rule must be defined to enable derivation of a suspense
account.
2.4.2.3.2.2 Suspense Account as Posting Credit Account
Rule Attribute Setup Guidelines
Rule Name RITS_SA_MAIN_CR
Rule Sub Type SA_MAIN_CR
Description Credit side posting (on suspense account)
Rule conditions D_POSTING_INVOCATION_CONTEXT =
BEFORE_IN_COMPLETE_OR_OUT_SEND
AND
P_MSG_CLASS = DD
AND
P_MSG_TYPE in (198_027,198_028)
Action
Account UID
2.4.2.3.2.3 Suspense Account as Posting Debit Account
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 51
Rule Attribute Setup Guidelines
Rule Name RITS_SA_MAIN_DR
Rule Sub Type SA_MAIN_DR
Description Debit side posting (on suspense account)
Rule conditions D_POSTING_INVOCATION_CONTEXT
BEFORE_IN_COMPLETE_OR_OUT_SEND
AND
P_MSG_CLASS = DD
AND
P_MSG_TYPE = 198_036
AND
MF_RITS_FLOW = S
Action Account UID
2.4.2.3.2.4 Compliance Validation - 21
Note: The Compliance Validation rule is a bypass rule and must be defined to enable GPP to skip
validation if warranted.
Rule Attribute Setup Guidelines
Rule Name RITS_COMP_BYPASS
Description RITS Compliance Validation Rule Bypass
Rule conditions P_CDT_MOP = RITS OR P_DBT_MOP = RITS
Action BYPASS
2.4.3 New Zealand - HVCS
2.4.3.1 Overview
HVCS (High Value Clearing System) is an electronic payment service used for high value inter-bank
transactions and for customer transactions where timeliness is important. Settlement is on a real-time,
transaction by transaction basis through ESAS.
The system has been operated by the Reserve Bank since October 2001 using the ESAS/SWIFT
interface, which in turn uses SWIFT FINCopy to pass settlement requests, authorizations and
confirmations between HVCS Participants.
ESAS is the system that:
• Holds the settlement accounts of financial institutions
• Enables the sender of an HVCS transaction to settle the value of the transaction by transferring the
value from the sender’s settlement account to the receiver’s settlement account.
ESAS is owned, operated, and managed by the Reserve Bank.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 52
Additional information related to HVCS:
Value
FIN Copy service identifier code AVP
Service Type FINCopy
Currency code NZD
Bank info party code NZ2SAWPACNZ2WXXX
Operating hours of HVCS Monday to Friday - from 09:00
Cut-off time Cut-off time for same day settlement:
Customer payments: 16:45
Bank to Bank payments: 10:00 (winter)/08:00 (summer time)
Inward Message Types MT103, MT202, MT205, MT205COV, MT202 COV, MT012,
MT019
Outward Message Types MT103, MT202, MT202COV, MT205, MT205
2.4.3.1.1 Same Day Cleared Payments (SCP) Operations
SCP is a product offered on the HVCS for customer payments to a domestic payee. These payments are
urgent and required to be transferred in half an hour.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 53
2.4.3.2 Flow Processes
The flow process for all Y-Copy RTGS is the same and supported by GPP. As NZ SCP is a Y-Copy
service type, see Y-Copy RTGS Flow Processes for a description of the process.
2.4.3.3 Inward/Outward Processing
2.4.3.3.1 Outward RTGS Payments
Outward customer payments to HVCS are held in GPP at the start of the RTGS day (09:00) as per
agreement between the NZ banks. Hold time is configured by the bank to hold these payments.
Outward CLS payments use the 'pay by time' functionality (in GPP SLA profile). The CLS time may be
received in field 13C or in field 72.
Field 52A is removed by GPP for outgoing SCP RTGS payments.
Outward HVCS payments perform posting after MT012/MT019 confirmation is received.
2.4.3.3.2 Inward RTGS Payments
Incoming payments from RTGS can result as one of the following:
• BOOK payment to bank’s customers
• RTGS payment (for example, agency bank)
• SWIFT payment to country correspondent.
For inward SCP payments, the debit value date is set as the processing date.
Fees are not charged for inward and return SCP transactions.
2.4.3.3.3 Method of Payment
Note: HVCS supports only same day value payments. No future dated payment is received from HVCS or
sent to HVCS. Payments may be routed to Schedule queue due to missed cut off for outgoing payments
to SCP.
Value date related set up on the Method of Payment profile ensures that:
• Backdated payments are not directed to HVCS
• Future dated payments are not sent to HVCS in advance. Future dated payments can be warehoused
in GPP.
2.4.3.3.4 Confirmation/Rejection Messages
Confirmation/rejection messages (MT012/MT019) are expected to be received for outgoing messages.
Payments wait for the message before proceeding to completion.
2.4.3.3.5 Reject/Return Messages
For an incoming payment, which falls into one of the manual queues, GPP allows a user to reject/return
the payment. GPP automatically generates an outward R-message linked to the original payment, and
performs the following actions:
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 54
• Replace sender and receiver in block 1 and block 2
• Field 21 is mapped from field 20 of the original message
• Fields 50, 52, 53, 54, 56, 57, 59 and 70 remain the same as those of the original message
• Field 72 is indicated as /RETN/
• Original message is sent to the Rejected or Returned queue
• Accounting is reversed
Outgoing return payments should be formatted as per HVCS guidelines. Line 4 of field 72 contains the
ESAS reference of the original payment Information from Service Administrator for Receiver bank
(received in block 3, tag 115).
2.4.3.3.6 Cancellation Messages
Cancellation Messages (n92, n96) for NZ SCP are sent via SWIFT MOP and follow the standard
Cancellation Flow.
2.4.3.4 Business Setup
Setup Additional Information
System Parameters N/A
Profiles MOP, Cut Off Times, Membership, Identifiers,
SLA Profiles
Rules MOP Selection, Clearing Cut-off Rules
Permissions N/A
Tasks N/A
Queues N/A
2.4.3.4.1 Profiles
These are the details of the required setup in GPP profiles for the Clearing Certification.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
2.4.3.4.1.1 Method of Payment Profile
To successfully identify the local office and the debit MOP, when an incoming message is received from
NZ SCP, local office’s BIC (provided in Block 1 of the incoming payment) should be set as a valid
identifier for this MOP In the MOP profile.
These are the specific attributes that need to be defined in the Method of Payment profile for SCP
Clearing for the New Zealand office.
Field Value for HVCS Comment
Name HVCS
Calendar Relevant calendar
or no value
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 55
Field Value for HVCS Comment
MOP Business Date Current business
day for the MOP The business date can be changed manually or by
an end-of-day task that advances the MOP business
date to the next valid business date for the MOP.
Value date extension 0 days Determines the limit for the future dated transactions
that are acceptable for the MOP.
Payments with value dates between the Max days
and the value date extension are validated for the
MOP and sent to the Schedule queue.
Currency NZD or no value If there is no value, all currencies are valid for the
MOP.
Settlement accounting Settlement
account with
ESAS
Membership Required Must be selected
Membership Type
MOP
Send Outgoing
message Must be selected
Settlement account
exists Must be selected
Cross office Must be selected
Processing Tab
FIN copy service AVP
Communication
preferences
Wait for
confirmation
2.4.3.4.1.2 Cut-off Times Profile
The Cut-off Times profile defines the latest time for transactions to be processed for HVCS MOP.
The HVCS calendar is required for the HVCS Clearing. The calendar sets the holidays and weekends
which are non-working days.
The HVCS Calendar profile for the office is defined under System Setup > Geographic Settings >
Calendars.
This is the suggested setup with specific attributes that need to be defined in the Cut-off profile for HVCS.
Field HVCS for Customer
Payment HVCS for Bank to
Bank Payments Comment
Cut-off name HVCS_cust HVCS_B2B
Cut-off type Clearing Clearing
Time zone NZ NZ Time zone for aligning cut-off
times
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 56
Field HVCS for Customer
Payment HVCS for Bank to
Bank Payments Comment
Description HVCS Clearing Cut-off
for customer payments HVCS Clearing Cut-off
for bank to bank
payments
Cut-off time 16:45 10:00
2.4.3.4.1.3 Membership Profile
The HVCS Membership profile defines whether the payment receiver and sender parties are members of
the clearing house. These are the specific attributes that need to be defined in the Membership profile for
HVCS.
Field Value for HVCS
MOP HVCS
Type of Membership Full member for HVCS participants (or associates)
2.4.3.4.1.4 Identifier Profile
The HVCS Identifiers profile is used to set up and view the party identifiers and settlement account
information for the MOP.
These are the specific attributes that need to be defined in the Identifiers profile for HVCS Clearing for the
Singapore office.
Field Value for HVCS Comment
MOP
HVCS
2.4.3.4.1.5 Service Level Agreement Profile
Service Level Agreement (SLA) defines specific payment processing commitments the bank is subjected
to. The SLA is one of the retail products the bank sells to provide added value to the payment processing.
The Service Level Agreement (SLA) profile is a rules-based mechanism for enrolling customers with
SLAs.
The SLA product as defined in the SLA profile is associated to the payment. This may be used as a
condition in calculating Fees.
Group Field Name Value for HVCS
General
Name
HVCS_SLA
Description Outward CLS payments
Product Select product
Process
Process Immediately Not selected
Hold x minutes before
pay-by- time Select to define number of minutes (delta) from pay-by-
time (CLS as accepted in Field 13 or 72) to process the
payment
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 57
2.4.3.4.2 Rules
2.4.3.4.2.1 MOP Selection
Rule
Name Description Attache
d to AND
/
OR
Field/Fiel
d Operator Value/
Field/
Function
Action
HVCS HVCS MOP
selection rule Local
office [Sttlm ccy] = NZD Set
MOP to
HVCS
2.4.3.4.2.2 Clearing Cut Off
In the following example, winter time is set to 5.10.2014-4.4.2015, any create date in this period returns
TRUE.
Rule
Name Description Attache
d to AN
D/
OR
Field/Field Oper
ator Value/Field
/Function Actio
n
WINTER
_SCHED Base
condition for
winter cut-off
period
NZ2 ( DATE_EXTRACT(Y
EAR,[P_CREATE_
DT])
= 2014
and (
( DATE_EXTRACT(D
AY,[P_CREATE_DT
]
>= 5 )
and DATE_EXTRACT(M
ONTH,[P_CREATE
_DT])
= 10 )
or ( DATE_EXTRACT(M
ONTH,[P_CREATE
_DT])
> 10 )
)
or DATE_EXTRACT(Y
EAR,[P_CREATE_
DT]
= 2015
and ( DATE_EXTRACT(D
AY,[P_CREATE_DT
]
<= 4
and DATE_EXTRACT(M
ONTH,[P_CREATE
_DT]
= 4
or DATE_EXTRACT(M
ONTH,[P_CREATE
_DT
< 4 )
)
HVCS_
CLS Clearing cut
off selection
for HVCS
NZ2 [Cdt MOP] = HVCS HVCS
_
CLS_
OR BASE_CONDITION
(WINTER_SCHED) = TRUE
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 58
Rule
Name Description Attache
d to AN
D/
OR
Field/Field Oper
ator Value/Field
/Function Actio
n
_W INTE
R
MOP- CLS
winter
payments
AN
D Msg type Cont
ains SWIFT_2
WINT
ER
HVCS_
CLS_
SUMME
R
Clearing cut
off selection
for HVCS
MOP- CLS
summer
payments
NZ2 [Cdt MOP] = HVCS HVCS
_
CLS_
SUM
MER
or BASE_CONDITION
(WINTER_SCHED) = FALSE
AN
D [Orgnl sttlm CLS
Time] Is not Empty
AN
D Msg type Cont
ains SWIFT_2
HVCS_
CUST Clearing cut
off selection
for HVCS
MOP-
customer
payments
NZ2 [Cdt MOP] = HVCS HVCS
_
CUST
and Msg type = SWIFT_103
2.4.3.4.2.3 Office SLA
Office SLA Rule (182) allows for a SLA profile to be assigned to the payment.
Rule
Name Descriptio
n Attache
d to AND
/ OR Field/Field Oper
ator Value/Field
/Function Actio
n
HVCS Sending
CLS
payments
on time
NZ2 Sttlm CLS Time Is not Empty HVCS
_SLA
2.4.4 Hong Kong - CHATS
2.4.4.1 Overview
Hong Kong's payment systems allow interbank transfers in the Hong Kong dollar (HKD), US dollar (USD),
and Renminbi (RMB). Hong Kong Interbank Clearing Limited (HKICL) is the operator of these payment
systems, providing banks with various interbank clearing and settlement services.
Clearing House Automated Transfer System (CHATS) is the local clearing system of Hong Kong
Monetary Authority.
• HK Dollar CHATS is Hong Kong’s national real-time gross settlement (RTGS) system.
• US Dollar CHATS provides settlement for USD transactions. It operates as an RTGS for USD
payments; the USD settlement institution is HSBC.
• Renminbi CHATS provides settlement for RMB transactions. It operates as an RTGS for RMB
payments. The RMB settlement institution is Bank of China (HK).
Additional information related to CHATS.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 59
Value
FIN Copy service identifier code HKL (all CHATS share the same FIN Copy Service)
Service Type Y-Copy
Currency code HKD, USD or RMB
Operating hours of HK CHATS 08:30 hours and 23:30 hours on all weekdays except 1 January
Cut-off time
CHATS USD and HKD MOPs:
• Customer payments cut-off 18:00
• Bank payments cut-off 18:30
CHATS RMB MOPs:
• Customer payments cut-off 23:00
• Bank payments cut-off 23:30
2.4.4.1.1 Calendars
CHATS HKD clearing operates in accordance with Hong Kong calendar.
CHATS RMB and USD clearings do not operate on Saturdays and Sundays, and on January 1, and
operates on Hong Kong’s public holidays.
2.4.4.1.2 Supported Message Types
The following message types is available for CHATS RMB, USD and HKD MOPs:
• MT103
• MT202
• MT202COV
• MT012: Sender Notification. Clearing to Participant
• MT019: Abort Notification. Clearing to Participant
• MT900
• MT910
Free Format messages (MT199, MT299) are initiated by a user by clicking on the Free Format button
from an existing payment and be sent via SWIFT.
The cancellation process in GPP is used for CHATS MOPs, using a cancellation request (MT192/292)
sent via SWIFT to the sender of the original payment. There are no changes to the GPP Cancellation
process for CHATS.
2.4.4.2 Inward/Outward Processing
CHATS is defined in GPP as a Method of Payment for RMB, USD and HKD. Respective MOP Selection
and validation rules need to be created to define the conditions in which CHATS MOP is selected and
used.
• CHATS membership information can be uploaded and maintained in GPP.
• MOP cut-off time and calendars is defined and maintained via business rules.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 60
• Additional mapping requirements for CHATS MOP need to be configured.
Backdated payments should not be sent to the clearing. This is defined by setting the Earliest value date
to 0.
For Confirmation levels, CHATS MOPs should be defined with the Communication preferences field set
as Wait for confirmation. This makes payments with credit MOP CHATS to move to the Wait Confirmation
queue.
For more information, see Business Setup.
2.4.4.2.1 FIN Copy Service in Incoming and Outgoing CHATS Payments
All CHATS MOPs share the same FIN Copy Service (HKL).
In order to identify the correct debit MOP of the incoming payment, the system rule ‘Adjust basic
properties’ needs to be configured to determine the Debit MOP based on the FIN Copy Service code and
the payment currency.
For outgoing CHATS payments, GPP maps the FIN Copy Service into Field 103 in Block 3 with the
respective FIN Copy Service indicated in the MOP profile.
2.4.4.2.2 Method of Payment
These Method of payment profiles are required for CHATS:
• CHATSHKD – Inbound and outbound HKD CHATS payments
• CHATSUSD – Inbound and outbound USD CHATS payments
• CHATSRMB – Inbound and outbound RMB CHATS payments
2.4.4.2.3 Future Dated Payments
CHATS allows future dated payments up to 12 calendar days. This can be achieved by setting the Latest
value date attribute to 12 in the MOP profile.
2.4.4.2.4 Return Message
A user can generate a return message from payment in a manual queue.
Once the user clicks Return, GPP triggers the Transaction generation mechanism to generate the
outgoing return payment. A new message page opens, which is linked to the original payment. The user
enters the Reject/Return reason code and submits it.
2.4.4.3 Flow
The flow process for all Y-Copy RTGS is the same and supported by GPP. As RITS is a Y-Copy service
type, see Y-Copy RTGS Flow Processes for a description of the process.
2.4.4.4 Business Setup
Setup Additional Information
System Parameters N/A
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 61
Setup Additional Information
Profiles MOP, Calendar, Clearing Cut-off,
Membership, Identifiers Profile Profiles
Rules MOP selection, Clearing Cut-off, calendar,
Mapping out Rules
Permissions As per customer’s requirement
Tasks
N/A
Queues N/A
2.4.4.4.1 Profiles
These are the details of the required setup in GPP profiles for the Clearing Certification.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
2.4.4.4.1.1 Method of Payment Profile
The CHATSHKD, CHATSUSD and CHATSRMB profiles should be setup with these preferences:
• Prevent sending backdated payments to the clearing, by setting the Earliest value date attributes to 0.
• CHATS MOPs should be setup with Communication preferences field as Wait for confirmation.
These are the specific attributes that need to be defined in the Method of Payment profile for HK CHATS
Clearing.
Field Value for HK
CHATS Comment
Name CHATSHKD/
CHATSUSD/
CHATSRMB
Different MOP profiles are required for HKD CHATS, USD
CHATS and RMB CHATS payments
Description CHATS HKD
Clearing
Calendar HKD If no calendar is assigned, the default calendar for the
office is used.
MOP Business
Date
Current business
day for the MOP
Value date
extension 0 Payments with value dates between the latest value date
and the value date extension is validated for the MOP and
then sent to the Schedule queue.
Currency HKD
Settlement
accounting HKL settlement
account
Membership
Required Must be selected
Membership type MOP
Membership check
level Metro BIC-8 level (Metro)
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 62
Field Value for HK
CHATS Comment
Send outgoing
message Must be selected
Settlement
account exists Must be selected
Processing Tab
FIN copy service HKL
Communication
preferences Wait for
confirmation
2.4.4.4.1.2 Calendar Profile
The Cut-off Times profile defines the latest time for transactions to be processed for CHATS Clearing.
Cut-off extensions are handled manually.
These are the specific attributes that need to be defined in the Cut-off Times profile for CHATS Clearing.
2.4.4.4.1.2.1 HKD CHATS Calendar
Field Value for
CHATS Comment
Calendar Name HKD
Description Hong Kong
Dollar
Calendar
Default calendar False
Weekend Days Saturday
Sunday
Indicates the days which are closed for business
Holiday Date TBD Indicates the date of public holidays which are closed for
business
Description TBD Description of the public holiday
2.4.4.4.1.2.2 USD CHATS Calendar
Field Value for
CHATS Comment
Calendar Name
CHATSUSD
Description CHATSUSD
Calendar
Default calendar
False
Weekend Days Saturday
Sunday
Indicates the days which are closed for business
Holiday Date January 1 Indicates the date of public holidays which are closed for
business
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 63
Field Value for
CHATS Comment
Description New Year Description of the public holiday
2.4.4.4.1.2.3 RMB CHATS Calendar
Field Value for
CHATS Comment
Calendar Name CHATSRMB
Description CHATSRMBC
alendar
Default calendar False
Weekend Days Saturday
Sunday
Indicates the days which are closed for business
Holiday Date January 1 Indicates the date of public holidays which are closed for
business
Description New Year Description of the public holiday
2.4.4.4.1.3 Cut-off Times Profile
The Cut-off Times profile defines the latest time for transactions to be processed for CHATS Clearing.
Cut-off extensions are handled manually.
These are the specific attributes that need to be defined in the Cut-off Times profile for CHATS Clearing.
2.4.4.4.1.3.1 HKD and USD CHATS
Field Value for HK & US
CHATS Comment
Department HKB
Office HK1
Cut-off name CHATSHKD or
CHATSUSD
Cut-off type Clearing
Time zone HKT UTC/GMT +8 hours
Description CHATSHKD or
CHATSUSD cut-off
Interim cut-off time 18:00 Customer payments cut-off
Final cut-off time 18:30 Bank payments cut-off
2.4.4.4.1.3.2 RMB CHATS
Field Value for
RMB CHATS Comment
Department HKB
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 64
Field Value for
RMB CHATS Comment
Office HK1
Cut-off name
CHATSRMB
Cut-off type Clearing
Time zone HKT UTC/GMT +8 hours
Description CHATSRMB
cut-off
Interim cut-off time 23:00 Customer payments cut-off
Final cut-off time 23:30 Bank payments cut-off
2.4.4.4.1.4 Membership Profile
The Membership profile defines whether the payment receiver and sender parties are members of the
clearing house.
The membership records are uploaded into GPP using the Profile Multi Action service.
These are the specific attributes that need to be defined in the Membership profile for HK CHATS
Clearing.
Field Value for
CHATS Comment
MOP CHATSHKD/
CHATSUSD/
CHATSRMB
Different MOP profiles are required for HKD CHATS, USD
CHATS and RMB CHATS payments
Type of Membership
Full member
Full member for HK CHATS participants (or associates)
2.4.4.4.1.5 Identifiers Profile
Identifiers profile is used to set up and view the party identifiers and settlement account information for
the MOP.
These are the specific attributes that need to be defined in the Identifiers profile for HK CHATS Clearing.
Label in Profile Value for
CHATS Comment
Department HKB
Office HK1
MOP CHATSHKD/
CHATSUSD/
CHATSRMB
Different MOP profiles are required for HKD CHATS, USD
CHATS and RMB CHATS payments
Identifier Select the relevant identifier for the local bank in the MOP
Account Select the settlement account that the local bank uses at
the MOP for payments exchanged with this MOP
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 65
2.4.4.4.2 Rules
GPP needs be configured to support the mapping out requirements of CHATS MOP regulations. Mapping
out rules are used to populate Transaction Types for the messages in F72, for example, MT103 and
MT202.
Each customer needs to define the values it requires.
2.4.4.4.2.1 MOP Selection Rule
• CHATSHKD needs to be setup for HKD payments in Hong Kong.
• CHATSUSD needs to be setup for USD payments in Hong Kong.
• CHATSRMB needs to be setup for RMB payments in Hong Kong.
CHATS MOPs selection rules should be attached at a higher hierarchy than SWIFT MOP.
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field/Field Operator Value/
Field/
Function
Action
CHATSR
MB MOP
Selection for
CHATSRM
B
HK1 [Sttlm Ccy] = RMB Set
CHATS
RMB
AND [Cdtr Agt
ctry] = HK
CHATSU
SD MOP
Selection for
CHATSRM
B
HK1 [Sttlm Ccy] = USD Set
CHATS
USD
AND [Cdtr Agt
ctry] = HK
CHATSH
KD MOP
Selection for
CHATSRM
B
HK1 [Sttlm Ccy] = HKD Set
CHATS
HKD
AND [Cdtr Agt
ctry] = HK
2.4.4.4.2.2 Clearing Cut off Rule
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field/Field Operator Value/
Field/
Function
Action
CHATSU
SDCUTO
FF
Clearing cut
off selection
for
CHATSUSD
MOP
HK1 [Cdt MOP] In CHATSU
SD Set
CHATS
USD
CHATSH
KDCUTO
FF
Clearing cut
off selection
for
CHATSHKD
MOP
HK1 [Cdt MOP] In CHATSH
KD Set
CHATS
HKD
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 66
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field/Field Operator Value/
Field/
Function
Action
CHATSR
MBCUTO
FF
Clearing cut
off selection
for
CHATSRM
B MOP
HK1 [Cdt MOP] In CHATSH
KD Set
CHATS
RMB
2.4.4.4.2.3 Missed Clearing Cut-off Rule
Missed clearing cut-off rule is invoked when the payment has missed an interim clearing cut-off but not
the final clearing cut-off. For CHATS clearing cut-off, a Missed clearing cut-off rule can be set to allow
bank payments to be processed in the interim time period.
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field/Field Operator Value/
Field/
Function
Action
MISSED
CHATSU
SDCLEA
R
Missed
clearing cut-
off for
CHATSUSD
bank
payments
HK1 [Cdt MOP] = CHATS
USD MAN_CL
EARING
[Msg tp] In SWIFT_
202,SW
IFT_202
COV
MISSED
CHATSH
KDCLEA
R
Missed
clearing cut-
off for
CHATSHKD
bank
payments
HK1 [Cdt MOP] = CHATS
HKD MAN_CL
EARING
[Msg tp] In SWIFT_
202,SW
IFT_202
COV
MISSED
CHATSR
MBCLEA
R
Missed
clearing cut-
off for
CHATSRM
B bank
payments
HK1 [Cdt MOP] = CHATS
RMB MAN_CL
EARING
[Msg tp] In SWIFT_
202,SW
IFT_202
COV
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 67
2.4.5 Singapore - MEPS
2.4.5.1 Overview
The Monetary Authority of Singapore (MAS) Electronic Payment System (MEPS+) is a real-time gross
settlement (RTGS) system developed for large-value Singapore dollar interbank funds transfers and the
settlement of Singapore Government Securities (SGS).
All banks in Singapore are eligible to participate directly in MEPS+. However, banks with a small volume
of Singapore Dollar (SGD) payments may choose not to participate in the system. Instead, such non-
participating banks may appoint participating banks as their agents to make SGD interbank payments on
their behalf.
In December 2006 MEPS+ was replaced with MEPS+, which included these improved features:
• use of SWIFT message formats and network
• advanced queue management capabilities
• automated collateralized intra-day liquidity facilities
• automated gridlock detection and resolution
Additional information related to MEPS+.
Value
FIN Copy service identifier code MEP
Service Type Y-Copy
Currency code SGD
Operating hours of MEPS-IFT Monday to Friday - 9:00 to 20:00
Cut-off time 19:00 - cut-off time for same-day settlement
2.4.5.1.1 Management
MEPS+ is owned and operated by MAS. All participating banks are contractually bound to operate in
compliance with the MEPS+ operating rules and regulations as stipulated by MAS.
Participating banks are charged on a cost recovery basis. A flat fee is charged for each message,
payable by the bank initiating the MEPS+ message. There is no annual subscription fee or joining fee to
participate in MEPS+, and no additional charge for real-time current account balance enquiries.
2.4.5.1.2 MEPS+ Operations
The MEPS+ system consists of two subsystems:
• MEPS+ Interbank Funds Transfer (MEPS-IFT).
• MEPS+ Singapore Government Securities (MEPS-SGS) – not supported by GPP.
Under the MEPS-IFT sub-system, interbank funds transfers are made using MEPS+ messages, derived
from SWIFT standards. As long as the paying bank has sufficient funds in its RTGS account, its same day
payment instructions are settled instantaneously and irrevocably. MEPS-IFT sub-system only processes
same day value transactions. However, the system also accepts forward-dated transactions which are
stored in the host database and processed on the actual value date.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 68
2.4.5.2 Message Types
As MEPS+ is a SWIFT based clearing, GPP supports the following SWIFT message types:
o MT103
o MT103+
o MT202
o MT202COV
2.4.5.3 Flow Process
The flow process for all Y-Copy RTGS is the same and supported by GPP. As MEPS+ is a Y-Copy
service type, see Y-Copy RTGS Flow Processes for a description of the process.
2.4.5.4 Inward/Outward Processing
2.4.5.4.1 Method of Payment
MEPS+ can be setup in GPP as an SGD Method of Payment. A respective MOP selection rule needs to
be created to define the scenarios in which MEPS+ is selected.
SWIFT standard validations are applied on outgoing payments to MEPS+.
Outgoing payments that missed MEPS+ cut-off time and no other relevant MOPs are available, are stored
in the Scheduled queue and processed on the next business day.
Value date related set up on the Method of payment profile ensure that:
• Backdated payments are not directed to MEPS+.
• Future dated payments can be sent to MEPS+ up to 14 business days in advance, unless the bank
requires warehousing the payments in GPP.
2.4.5.4.2 Confirmation/Rejection Messages
Confirmation/rejection messages (MT012/MT019) are expected to be received for outgoing messages.
Payments wait for the message before proceeding to completion.
2.4.5.4.3 Reject/Return Messages
For an incoming payment which falls into one of the manual queues GPP allows a user to reject/return
the payment. GPP automatically generates an outward R-message linked to the original payment, and
perform the following actions:
o Replace sender and receiver in block 1 and block 2
o Field 21 is mapped from Field 20 of the original message
o Fields 50, 52, 53, 54, 56, 57, 59 and 70 remain the same as those of the original message
o Field 72 is indicated as /REJT or /RETN
o Original message is sent to the Rejected or Returned queue
o Accounting is reversed
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 69
2.4.5.4.4 Cancellation Messages
Cancellation Messages (n92, n96) for MEPS+ are sent via SWIFT MOP and follow the standard
Cancellation Flow.
2.4.5.5 Business Setup
Setup Additional Information
System Parameters N/A
Profiles MOP, Cut Off Times, Membership, Identifiers. Profiles
Rules MOP selection, Clearing Cut-off, Office Hold
Until Time Rules
Permissions N/A
Tasks N/A
Queues N/A
2.4.5.5.1 Profiles
These are the details of the required setup in GPP profiles for the Clearing Certification.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
2.4.5.5.1.1 Method of Payment Profile
To successfully identify the local office and the debit MOP, when an incoming message is received from
MEPS+, local office’s BIC (provided in Block 1 of the incoming payment) should be set as a valid identifier
for this MOP In the MOP profile.
These are the specific attributes that need to be defined in the Method of Payment profile for MEPS+
Clearing for the Singapore office.
Field Value for MEPS+ Comment
Name MEPSPLUS
Calendar Relevant calendar or
no value
MOP Business
Date Current business day
for the MOP The business date can be changed manually or by an
end-of-day task that advances the MOP business date to
the next valid business date for the MOP.
Value date
extension 14 days Determines the limit for the future dated transactions that
are acceptable for the MOP.
Payments with value dates between the Max days and the
value date extension are validated for the particular MOP
and sent to the Schedule queue.
Currency SGD or no value If there is no value, all currencies are valid for the MOP.
Settlement
accounting Settlement account
with MEPS+
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 70
2.4.5.5.1.2 Cut-off Times Profile
The Cut-off Times profile defines the latest time for transactions to be processed for MEPS+ MOP.
The MEPSPLUS calendar is required for the Singapore MEPS+ Clearing. The calendar sets the holidays
and weekends which are non-working days in Singapore.
The MEPS+ Calendar profile for Singapore office is defined under System Setup > Geographic Settings >
Calendars.
These are the specific attributes that need to be defined in the Cut-off profile for MEPS+ Clearing for the
Singapore office.
Field Value for MEPS+ Comment
Cut-off name MEPS
Cut-off type Clearing
Time zone SGT Time zone for aligning cut-off times
Description MEPSPLUS Clearing
Cut-off
Membership Profile
The MEPS+ Membership profile defines whether the payment receiver and sender parties are members
of the clearing house.
These are the specific attributes that need to be defined in the Membership profile for MEPS+ Clearing for
the Singapore office.
Field Value for MEPS+ Comment
MOP MEPS
Type of
Membership Full member for
MEPS+ participants
(or associates)
2.4.5.5.1.3 Identifiers Profile
The MEPS+ Identifiers profile is used to set up and view the party identifiers and settlement account
information for the MOP.
These are the specific attributes that need to be defined in the Identifiers profile for MEPS+ Clearing for
the Singapore office.
Field Value for MEPS+ Comment
MOP MEPS
2.4.5.5.2 Rules
These are examples of user defined rules.
2.4.5.5.2.1 MOP Selection
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 71
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
MEPS
PLUS N/A MEPSPLUS
MOP
selection rule
Local
office [Sttl
m
Ccy]
= SGD SET MOP
Profile
MEPSPLU
S
AND [Msg
tp] IN SWIFT_1
03,
SWIFT_2
02
AND [Cdtr
Agt
ctry]
= SG
2.4.5.5.2.2 Clearing Cut Off
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
MEPS
PLUS N/A MEPSPLUS
cut off
selection rule
Local
office [Cdt
MOP
]
= MEPSPL
US SET
MEPSPLU
S cut off
(19:00)
2.4.5.5.2.3 Office Hold until Time
This rule is used to hold payments in GPP until MEPSPLUS opening time is reached.
Rule
Name Rule
Sub
Type
Description Attached
to AND/
OR Field Operator Value/
Field/
Function
Action
MEPS
PLUS
OPEN
TIME
N/A MEPSPLUS
opening time Local
office [Cdt
MOP
]
= MEPSPL
US SET Hold
until time to
06:00 AM
2.4.6 Malaysia - RENTAS
2.4.6.1 Overview
RENTAS is a multi-currency real time gross settlement system in Malaysia. RENTAS multi-currency
enables payment instructions between RENTAS members to be processed and settled individually and
continuously throughout the working day. RENTAS is operated by the Bank’s wholly-owned payment
subsidiary, Malaysian Electronic Clearing Corporation Sdn. Bhd. (MyClear).
The participating banks in RENTAS comprises of Commercial Banks, Islamic Banks, Investment Banks
and Development Financial Institutions.
RENTAS was initially implemented in proprietary format in July 1999. In March 2014, SWIFT was being
adopted as access channel to connect to the new RENTAS system.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 72
Additional information related to RENTAS:
Data Description
SWIFT service identifier code RENTAS/IFTS
Service Type SWIFT V-Topology Messaging Scheme
Currency code MYR, CNY, USD
Operating hours of RENTAS Monday to Friday - 9:00 to 17:00
Cut-off time Cut-off time for same-day settlement
For MT103: Final Cut off is 4:00 PM
For MT202: Final Cut off is 6:00 PM
2.4.6.1.1 RENTAS Currencies
RENTAS supports settlement in these currencies:
• Malaysian Ringgit (MYR): Fully owned by the Domestic Central Bank, Bank Negara Malaysia (BNM).
• Chinese Yuan Renminbi (CNY): In 2011, Bank Negara Malaysia (BNM) appointed Bank of China
(Malaysia) Berhad (BOCM) as the Onshore Settlement Institution for Renminbi in RENTAS.
• US Dollar (USD): OSI is CIMB Bank Malaysia.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 73
2.4.6.2 Message Types
RENTAS SWIFT adopted ISO 15022 messages. GPP supports the following SWIFT message types.
Message Type Description Inward/
Outward
1.
MT103 Single Customer Transfer message I/O
2. MT202 General Financial Institution Transfer I/O
3. MT102 Multiple Customer Credit Transfer I
4. MT203 Multiple General Financial Institution Transfer (Roadmap
release for Q1 2016) I
5. MT900 Confirmation of Debit I
6. MT198/ MT298 Tag 12
Credit Notification 110 – Advice of Charges, Interest and Other
Adjustments. These messages are non-accounting messages.
I/O
7.
MT198 120 – Customer Transfer Tracking I/O
8.
MT192 Request of Cancellation of MT103 O
9. MT292 Request of Cancellation of MT202 O
10. MT198/298/998 Tag 12
200 - Transaction Processing Status Update
Response to MT1xx, 2xx and 9xx Messages
500 - Settlement Status (Pending Advice)
Note: The MTn98 message is listed along with its value in tag
12 which is used for a different business purpose.
I
11.
MT199/299/999 Free Format Message I/O
2.4.6.3 Flow Process
RENTAS uses the SWIFT V-topology messaging scheme (instead of the FIN Y-copy messaging scheme)
in order to allow participant(s) who may not be a SWIFT member to still participate in the system.
The member bank uses BIC1 (non-connected BIC) and its principal member bank BIC in the header, to
exchange message via SWIFT to RENTAS.
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 74
This image shows the exchange of application messages of a successful credit transfer:
2.4.6.4 Inward/Outward Processing
GPP supports:
• Single Payments:
o Single Customer Credit Transfer Message Flow (MT103): This message is sent by or on behalf of
the financial institution of the ordering customer, directly or through (a) correspondent(s), to the
financial institution of the beneficiary customer. It is used to convey a funds transfer instruction in
which the ordering customer or the beneficiary customer, or both, are non-financial institutions.
o General Financial Institution Transfer Message Flow (MT202): This message is sent by or on
behalf of the ordering institution directly, or through correspondent(s), to the financial institution of
the beneficiary institution. It is used to order the movement of funds to the beneficiary institution.
• Multiple Customer Credit Transfer Message Flow (MT102)
• Multiple General Financial Institution Transfer Message Flow (MT203)
• Credit Notification Message Flow (MT198/MT298, sub type 110)
• Credit Transfer Cancellation Message Flow (MT192/MT292)
• Free Format Message Flow (MT199/MT299/MT999)
• Adhoc Cash Statement Request Message Flow
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 75
GPP handles specific validations required by RENTAS to support the process. In addition, GPP supports
inward MT198 payments which represent Rejection/Pending Advices, as well as for incoming MT900
payments which represent Completion advices.
2.4.6.4.1 Outward MT103 & MT202 from Sender Bank
Description of Single Payment workflow for MT103 or MT202:
1. RENTAS receives an MT103 or MT202.
2. RENTAS provides the MT198-200 Rejection/Pending Advice to the sending bank, followed by the
MT900 Debit confirmation advice (post settlement of the funds).
3. RENTAS then forwards the same message (MT103 or MT202 by changing the header) as
Confirmation Advice to the receiving bank for further credit to the beneficiary’s account.
4. The receiving bank must generate a MT198-120 Customer Transfer Tracking to the sending bank via
RENTAS for an inward MT103 payment.
For RENTAS CNY payments identified with a specific TRN code, MyClear performs special validations as
follows:
• CNY02 - Transfer to Mainland by Individual (only for outward MT103 from GPP).
• CNY03 - Transfer to Mainland by Company as trade payment (for both outward MT103 and outward
MT202 from GPP).
• CNY04 - Transfer to Mainland for Investment (for both outward MT103 and outward MT202 from
GPP).
• CNY05 - Transfer to All Offshore Destination Other Than Mainland (for both MT103 and MT202 from
GPP).
Clearing Processing Generic Clearing Processing
Global PAYplus Business Guide Page 76
• CNY06 - Transfer from Offshore to Local PB (both inward MT103 and MT202 to GPP).
GPP performs validations on CNY02 to CNY05 outward RENTAS CNY payment. CNY06 is considered as
a normal inward RENTAS CNY payment and no special processing is performed by GPP. It is expected
that MyClear performs the necessary validations.
2.4.6.4.2 Outward Cancellation request from Sender Bank
Outward requests for cancellations are supported by GPP. However, as per RENTAS requirements, a
request for cancellation can only be generated when specific conditions are met. The Cancel Request
button is available only when the appropriate conditions apply:
• A Cancellation Request Status Update was not received yet
• Payment status is Wait Confirmation
In addition, GPP supports inward MT198 payments which stand for Status update of Cancellation
Request. These payments are handled by GPP as technical ACK/NAK that mark the status of
cancellation requests.
GPP also supports inward MT198 payments which report when the transaction has been cancelled; GPP
sets the original payment status to be cancelled.
2.4.6.4.3 Customer Transfer Tracking Message
As part of RENTAS implementation, GPP supports receiving and sending of MT198^120 message. GPP
sends MT198^120 message to RENTAS on successful completion of message.
For incoming MT198^120 message from RENTAS, GPP matches the original MT103 message.
2.4.6.4.4 Processing of MT199/MT299
GPP supports generation of MT199 and MT299 from the original message. For RENTAS, GPP performs
additional mapping in the MT199/MT299 message, in order to comply with RENTAS specification.
As part of RENTAS implementation, GPP receives MT198^200 message for the MT199/MT299
messages rejected by RENTAS.
2.4.6.4.5 Return Messages for RENTAS
For RENTAS, GPP processes an incoming and outgoing return message. Specific mapping is required
for a RENTAS outward return message.
An incoming return message is processed as a normal return message. GPP retrieves the incoming
return message from RENTAS by (CREDIT RETURN) string in Field 70 (for MT103 return) or in Field 72
(for MT202 return).
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 77
3 Mass Payment Clearings
3.1 Mass Payment EU Clearing
3.1.1 Austria - CS.A
3.1.1.1 Overview
The Austrian National Bank (OeNB) introduced the Clearing Service Austria (CS.A) domestic payment
transaction service in order to improve Austria domestic payment processing and increase accessibility of
the national and international payment systems in accordance with the ECB policy statement. The GSA
(Geldservice Austria) has operated CS.A since 2011.
The CS.A clearing system offers Austrian financial market an infrastructure for processing and settling all
domestic payment orders (credit transfers and debits) in Euro. CS.A minimizes costs and risks by
processing noncash interbank retail payments and domestic payment transaction messages.
The core function of the system is to accept national interbank retail payments in defined formats, to
process them, and to prepare and proceed with settlements. Processing involves accepting payment
orders from Austrian sending banks, and directly transferring them to Austrian receiving banks via CS.A.
This method reduces both the number of transactions and the amount of liquidity required for settlement.
Additional information related to CS.A:
Value
Currency code EUR
Operating hours Daylight Settlement: 07:15 until 17:35 Monday to
Friday
Night Settlement: 19:00 until 07:05
Cut-off time For details, see Cutoffs (Determination of Final
Balances)
3.1.1.1.1 Transmission of Payment Orders
Data, i.e. payment orders, are received and sent through CS.A in the form of files with defined formats.
Each file consists of one or more bulks containing one or more individual payment orders.
3.1.1.1.2 Validation of Incoming Payment Orders
Immediately after a payment order has been received, the files are validated by the CS.A system (for
example, checked for syntax errors). After validation, the system sends a confirmation message in which
the participant is informed whether the batch, file, or transaction delivered can be processed or whether
errors have occurred, and if so, which ones.
3.1.1.1.3 Cutoffs (Determination of Final Balances)
3.1.1.1.3.1 Cutoffs for Payment Orders with Value Date D
At the cutoff times each participant’s short or long position is calculated by netting. This final balance is
the basis for settlement, which is debited or credited to the participant’s TARGET2 account in the next
settlement cycle. Moreover, the system automatically checks whether the participant has sufficient
liquidity for settlement.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 78
The breakdown into several cutoff times serves to distribute the clearing load and takes participants’
liquidity management needs into account. Payment orders that are to be settled on the same day must be
delivered by cycle ‘X0X16’ ending at 16:00 at the latest. Any payment messages that are delivered later
than that are processed on the next business day and the value date is automatically adjusted
accordingly.
3.1.1.1.3.2 Pre-valued Payment Orders
Payment orders may also be delivered with a future value date. Payments can be sent up to one day in
advance.
3.1.1.1.3.3 Settlement
The net positions are sent to the settlement agent for settlement. Once the settlement system has
successfully given the CS.A confirmation of the transfer of the net positions, the payment orders which
have been received are considered final (irrevocable under the Finality Act).
The TARGET2 system is used as the platform for the execution of settlement. In TARGET2, every direct
participant uses a main account and a subaccount.
Settlement in TARGET2 is performed by using the Ancillary System Interface (ASI). Various procedures
may be used within the ASI. CS.A allows settlement on dedicated accounts without being influenced by
other payment procedures. To use this procedure, a TARGET2 subaccount must first be established for
every direct participant.
3.1.1.1.4 Message Types
Message Type Description
SEPA Credit
Transfer (SCT) pacs.002 Status Notification
pacs.004 Payment Return
Refund
pacs.008 Customer Credit Transfer
camt.056 Payment Cancellation Request
camt.029 Resolution of Investigation; used to inform of the resolution
of a recall.
3.1.1.2 Use Cases
CS.A is based on SEPA, so inward and outward flows and process are the same. For information about
SEPA use cases, see the GPP Business Guide SEPA.
3.1.1.2.1 SEPA Credit Transfer (SCT) Use Cases
Basic SEPA Use Case Alternate SEPA Use Case
Outward SCT via STEP2 Outward SCT is Warehoused
Outward SCT Fails Processing
Outward SCT with Incoming Validation file
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 79
3.1.1.2.2 Outward SEPA Credit Transfer - Mass Payment with CS.A
Use Case Name Mass Payment with CS.A
Actors Channels, Initiating party, User, Banks core systems, clearing gateway.
Description This use case defines the End To End outward flow to CS.A clearing.
Trigger Initiating party (such as an FI’s customer) sends a file containing multiple
credit payment transactions
Message is routed to MP flow (MP MOP is selected) from a different flow.
Pre-conditions Payment initiation is well-formatted and has mandatory information as defined
by pain message (pain.008, pain.001) rules.
Post-conditions Payment is completed successfully.
Definition of Done MP file is sent to Clearing.
Positive flow GPP receives a file containing multiple credit payment transactions and can
process it successfully to complete using MP Clearing method of payment.
Negative flows File or batch has been rejected by the Clearing
GPP cannot process the whole file successfully and payments are routed to
manual intervention queue with an error, or rejected back to the customer (as
per setup).
The flows are included in the GPP Business Guide SEPA, based on to the SEPA rule book and
guidelines. For a description of the process, see Outward Mass Payment with CS.A.
3.1.1.2.3 Outward SEPA Credit Transfer - Validation Files from Clearing (file, bulk, and transaction level)
Use Case Name Support Rejects from Clearing
Actors Debtor bank for CT, Creditor bank for DD
Description Erroneous information within the outgoing file can lead to rejects in CS.A.
The reason for the rejection can appear on the following levels: file, bulk and
transaction. (same as SEPA processing)
Trigger CS.A in response to outgoing file.
Definition of Done This use case is done once GPP receives the reject and updates the outgoing
transactions status accordingly
Positive flow GPP can process all three levels of rejection status by pacs.002 meaning set
to reject all relevant transactions.
Negative flows The system cannot process the rejection file.
3.1.1.2.4 Outward SEPA Credit Transfer - R-Messages
The process for R-message requests (Recall, Return, Refund) is the same as SEPA processing.
Use Case Name Outward SEPA Credit Transfer - R-Messages
Actors camt.056, pacs.004, camt.029
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 80
Use Case Name Outward SEPA Credit Transfer - R-Messages
Description GPP handles through CS.A a Recall request initiated by the bank or customer
and a return request sent from the receiving financial institution.
Trigger
Recall, return, refund requests by the customers or bank users
Pre-conditions Original payment was processed in GPP
Positive flow GPP handles the Recall, return, refund successfully
3.1.1.2.5 Outward SEPA Credit Transfer - Legal Holiday Good Friday
The Austrian national government recognizes Good Friday as a legal holiday. In Austria, this holiday is
typically observed on the Friday preceding Easter Sunday.
In Austrian bank-to-bank payment transactions, Good Friday is treated as a payment transactions
holiday, which requires special handling.
Since Good Friday is a TARGET-holiday, the Euro-System does not accept bookings in central bank
money. Consequently, the booking of settlement positions is performed with the value date of the
Tuesday after Easter Sunday.
Use Case Name Legal Holiday Good Friday
Actors Customer files (outgoing)
Description CS.A performs all cut-offs. Incoming messages are validated and forwarded
in case of a necessary as well as successful assurance.
Pre-conditions Setup of Austrian calendar, Setup of Euro calendar
Positive flow GPP advance the transactions to Tuesday after Easter.
3.1.1.3 Inward/Outward Processing
3.1.1.3.1 Outward Mass Payment with CS.A
GPP processes the payment based on the SEPA outward Mass Payment processing with the following
adjustments for CS.A clearing.
• CS.A accepts only transaction in Euro
• CS.A has no file size restrictions for incoming files. Bulking Profile setup is defined by the customer.
• Pure cut-off without immediate following settlement (D and D-1):
o 08.30 a.m. (X0C08)
o 10.30 a.m. (X0C10)
o 2.00 p.m. (A1C14)
o 4.00 p.m. (A1C16)
• Sub group: Night cut-offs (D and D-1):
o 10.00 p.m. (A1N22)
o 03.00 a.m. (A0N03)
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 81
• Cut-offs with immediate settlement (only D):
o 12.45 p.m. (X0X12)
o 3.00 p.m. (X0X15)
• Pure Settlement (only D):
o 08.00 a.m. (A0S08)
• Forwarding of pure Cut-offs of (uncollateralized) Immediate Forward Messages (D and D-1):
o 11.45 a.m. (A0V11)
o 7.00 p.m. (A1V19)
• Cycle name key:
o First Position = Sub-system:
A…for CS.A
X…for CS.A and CS.I (combined)
o Second Position = value recognition:
0…same-day
1…pre-valuated
o Third position = Type/characteristic:
N…for Night cut-offs
C…for pure cut-off (= without settlement)
S…for pure settlement
X…for cut-offs with settlement
V…for pure message sending (e.g. exclusive forwarding of immediate forwards)
Z…for contingency cut-offs (with or without settlement)
o Fourth position=time component:
Regularly planned time of cut-off/settlement; 2-digits, therefore display of hour only, e.g. 08 (=
Cut-off at 08.30), 12 (= cut-off with settlement at 12.45) etc.
For more information, see Method of Payment Profile.
3.1.1.3.2 Cut-off Time
This table describes the last possible cut-off time based on the settlement date D for each transaction
type.
• Credit Transfers
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 82
In case of SCT Returns/Refunds, CS.A does not validate the cut-off times, consequently they are not
mentioned in the table.
• Channels:
Files must be presented through an authorized communication channel: SWIFTNet FileAct or
connection via a dedicated line. For files in SEPA or EDIFACT format, CS.A participants can use
these channels interchangeably between participating banks for delivery to the clearing service, as
long as the necessary connectivity tests have been successfully completed.
SWIFTNet FileAct: Files in EDIFACT or XML format can be exchanged via this channel. The data
presentation by SWIFTNet FileAct can only be performed in ‘push mode’, whereby both partners
must be online in the SWIFT-network in order to transfer the file.
Connect directly via a dedicated line. This is an alternative option for the delivery of files in EDIFACT
and XML format.
• Value Date: The presenting times are defined as follows:
o Pre-value Date: All payments can be send to the Clearing Service 14 calendar days before the
stated Interbank Settlement Date. An exception applies for special value transactions, which can
be presented up to 60 calendar days before the stated Interbank Settlement Date. Payment
orders which do not comply with these pre-value date presenting times – after a possible new
value date is set – will be rejected by the system (with pacs.002 RJCT).
o Back Valuation: Payments generally do not have back valuation; when the last cut-off for
processing is missed or there is a (several days) back valuation due to technical malfunction,
CS.A performs an automatic set of a new value date to the next possible CS.A business day with
a possible reject due to deadline violation.
The value date cannot be more than 14 calendar days in the past; otherwise, the whole bulk
(even after set of a new value date) is rejected. This re-valuation due to technical malfunction to
the next possible CS.A business day is send to the presenter with a pacs.002 ACWC message.
In general, as part of the value date calculation in GPP if it is a back value payment GPP will advance
to the next BD if it is allowed according to the setup (role value date)
• Calendar: CS.A requires setup of Austrian calendar and Euro calendar – use combined calendars.
For more information, see Outward SEPA Credit Transfer - Legal Holiday Good Friday and Calendar
Selection Rule.
• Data formats and types of business: The following formats and message types are processed on the
entry side by CS.A:
o SEPA Credit Transfer (SCT): pacs.002 (only status messages), pacs.004, pacs.008, camt.056,
camt.029
• File Re-send and Storage
GPP supports storing outgoing files at least one day after settlement, for cases of contingency. A
GPP user can select one or more files and click Re-send to simply send out one or more physical
files.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 83
The file(s) is placed in the relevant connection point to be picked up by GPP for outgoing messaging.
Upon resending the file(s), a notification bar displays above the grid and reports how many items
failed and how many items succeeded in the group action.
Note: This action is bound to dual control policy, if configured by the bank. No accounting is
completed or tracked with this function.
3.1.1.3.3 Validation Files from Clearing
Each file sent to the Clearing Service must pass a two-level validation process:
• File level: Provides a thorough technical validation on the file
• Bulk level: Provides validations about the file’s entitlement for the presentation of transactions in a
certain format, as well as the name of the other transaction participant.
The presenter of the file must be an entitled member of CS.A, otherwise GPP rejects the file and
processing does not proceed. After receiving an incoming file and preforming the basic validations, CS.A
provides a pacs.002 format (multi bulk) to the presenter to acknowledge file receipt and validation or, to
initiate an alert that indicates possible errors with the bulk of a file.
Process Statuses
Status Description
ACTC Accepted Technical Validation. This value is initiated as a reply to a positive
validation of the received bulk. However, rejects of individual transactions or a
complete reject are still possible.
ACWC Accepted with Change. This value is used in if a revaluation occurs, due to system
problems on the side of the Clearing Service. It can also be used when setting a new
value date due to technical malfunction on the participant’s side or for revaluated
bulks. Rejects of included single transactions or a complete reject are still possible
(bulk level).
RJCT Rejected. The complete bulk is rejected.
PART Partial. Partial transaction rejection.
Examples:
• Example 1: Successful bulk validation is immediately confirmed via pacs.002 ACTC. After successful
processing (collateralization/blocking), CS.A delivers the bulk message.
• Example 2: If a file does not pass the technical validation, for example, if there is a technical
malfunction, or, if the file is sent on a weekend, the bulk delivery is delayed.
When the bulk delivery is delayed, pacs.002 ACTC immediately confirms a successful bulk validation.
CS.A sends a pacs.002 ACWC to indicate that the value date has changed.
After successful processing (collateralization/blocking), CS.A delivers the bulk to the receiving
participant on the (new) value date. The outgoing bulk contains the new value date.
• Example 3: A transfer bulk in SEPA format is rejected in case of a same-day illiquidity, with a timely
bulk delivery.
Successful bulk validation is immediately confirmed via pacs.002 ACTC, but processing fails due to
illiquidity. Single transactions of the bulk are rejected via pacs.002 PART.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 84
• Example 4: A re-valuation (due to system problems) and subsequent illiquidity, which leads to reject
of the SEPA transfer bulk:
A successful bulk validation is immediately confirmed via pacs.002 ACTC. CS.A performs a re-
valuation due to system problems and immediately reports it via pacs.002 ACWC.
Further processing fails due to illiquidity. Single transactions of the bulk are rejected via pacs.002
PART.
3.1.1.4 Business Setup
3.1.1.4.1 Profiles
3.1.1.4.1.1 Method of Payment Profile for SCT
These are the specific attributes that need to be defined in the MOP profile for CS.A Clearing.
Field Name Value
Name CSA_SCT
Description MP CT MOP for CSA clearing
Calendar EURO calendar
Advance to day after holiday Selected
Roll forward at start of day Selected
Earliest value date 0
Latest value date 1
Value date extension 365
Settlement account exists Selected
Currency EUR
Min. amount 0.01
Max. amount 999.999.999,99
Validations
Membership required Selected
Membership check level Metro
Type MOP
MOP can be selected by user Selected
Send outgoing message Selected
Allow force from scheduled queue Selected
3.1.1.4.1.2 Cut-off Times Profile
The Cut-off Times profile for each MOP is defined in the Default Cut-off Name field in the Method of
Payment profile.
Field Name Value
Cut-off Name CSA_SCT MOP
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 85
Field Name Value
Default Time Selected
Cut-off Type Clearing
Time Zone CET
From Date N/A
To Date N/A
Interim Cut-off Time 16:00
Final Cut-off Time 16:00
3.1.1.4.2 Rules
GPP uses the Calendar Selection rule to dynamically select the relevant calendars for each payment.
Calendar Rules define the relevant calendars that are considered on business day assessment.
The Calendar Selection rule uses a calendar combination to ensure that the payment value date is a
business day for the concatenated calendar. If the payment value date is a non-business day, the
payment value date is advanced to the next business day.
The appropriate rule type is triggered by the MOP assessment process, and defines these calendars:
• The Office calendar uses the local Austrian calendar
• The MOP calendar uses the Euro calendar. The Calendar Selection Rule defines the combined
calendar set that is used in MOP value date calculations.
3.1.1.4.2.1 Calendar Selection Rule
Rule Attribute Set Up Guidelines
Rule Name CSA_MP_COM_CAL
Description The MOP value date calculations can be based on the following
calendars:
Local Office (Austrian calendar)
Euro Calendar
Attachment Local Office
Rule conditions If Debit currency = EUR add Euro calendar
Or If Credit currency = EUR add Euro calendar
Action Add calendar – the specified calendar is added to the combined
set. If no matching rule is determined, then all calendars are
used
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 86
3.2 Mass Payment Africa Clearing
3.2.1 South Africa - AC
3.2.1.1 Overview
Authenticated Collection (AC) is a direct debit clearing system introduced by the South African Reserve
Bank (SARB). This clearing system was introduced in order to protect both sides of direct debit
transaction from abuse of the debit order by performing the following:
• Providing consumers upfront knowledge about their debits through an electronic authentication
process
• Ensuring that debits are authorized legally and rule out any cash flow management strategies from
abusive consumers
Additional information related to AC.
Value
Currency codes ZAR
Operating hours AC clearing system operates on all week days including weekends and
public holidays.
Settlement of Inward Debit Responses are NOT performed by AC on
Sunday and Public Holidays. On these days, AC only receives,
processes and sends files. When a Debit Response is received by AC on
Sunday or a Public Holiday, AC holds the request and performs the
settlement on the next business date.
For more information, see
Operating Hours.
Clearing Model Direct Debit Clearing
3.2.1.1.1 Operating Hours
AC clearing system’s operating hours and cut-off times for receiving and sending files for direct debit
requests and responses are different for weekdays (Monday to Friday) and Saturday, Sunday and Public
Holidays.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 87
Weekdays (Monday to Friday) Operating Hours
Saturday, Sunday and Public Holidays Operating Hours
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 88
3.2.1.1.2 High Level Business Flow
The flow shows the end to end business flow of direct debit requests and confirmation messages being
sent between the creditor bank, AC Clearing and debtor bank.
• Direct debit requests (pacs.003) are originated from a creditor or a creditor bank. They are sent via
the AC clearing (ACH) to the relevant debtor banks, and are ultimately applied to debtor’s accounts.
• Responses to direct debits requests (pacs.002) are returned by the debtor bank via the AC clearing to
creditor banks and/or creditors. Successful debits are applied to interbank settlements by AC
clearing.
• AC clearing validates inwards direct debit requests (pacs.003) and debit responses (pacs.002) and
triggers a status report to the creditor bank or the debtor bank respectively with the status of the
message validation.
3.2.1.1.3 Supported Message Types
Message Type Description
pacs.003 Direct Debit Message
pacs.002 Debit status report – positive or negative response from clearing. In
addition, pacs.002 is also sent as a debit response from the debtor bank.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 89
3.2.1.2 AC Use Cases
Basic Use Case Alternate Use Case
Outward Direct
Debit (Creditor) to
AC
Outward DD with Reject Status Report from AC
Outward DD with Partially Accepted Status Report from AC
Outward DD with Success Status Report from AC and Reject Debit Response
from Debtor Bank via AC
Inward Direct
Debit (Debtor)
from AC
Inward DD with successful Outward DD Response
Inward DD with Reject outward Debit Response followed by a successful Inward
Status Report from AC
Inward Direct Debit Receives NSF from Accounting System
3.2.1.2.1 Outward Direct Debit (Creditor) to AC
Use Case Name Outward Direct Debit to AC
Actors
Initiating Party, Creditor Bank, Banks core systems, AC clearing.
Description This flow defines the outward direct debit mass payment via AC clearing
Trigger Initiating party (such as a bank customer) sends a pain.008 file containing
multiple direct debit payment transactions.
Pre-conditions Payment initiation is well-formatted and has mandatory information as defined
by ISO format specification
Post-conditions Payment is completed successfully.
A file is generated and sent to AC
Basic flow GPP receives a file containing multiple direct debit payment transactions and
able to process and send it successfully to AC clearing. GPP then receives a
successful confirmation messages from AC and debtor bank which results in
direct debit completion.
Alternate flows • Outward DD with Reject Status Report from AC
• Outward DD with Partially Accepted Status Report from AC
• Outward DD with successful response from AC and Pending Debit
Response from Debtor
• Outward DD with successful response from AC and Reject Debit
Response from Debtor
3.2.1.2.1.1 Outward DD with Reject Status Report from AC
This alternate business use case describes a positive flow in which GPP successfully triggers an outward
direct debit and receives a successful Status Report followed by a successful Debit Response from AC
clearing.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 90
AC_MP_1.1 - Outward Direct Debit via AC Clearing
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
Creditor Bank’s
GPP MP Processing
Clearing
Service
GPP Integration Clearing Gateway Debtor Bank
Incoming Customer
file (pain.008)
Can be wrapped
with Fundtech Msg
File processing
Pre-Processing
Transactions
Sub-batch
generation
Sub-batch
Completion
Customer
Acknoledge
ment
Individual tx
in Wait
Confirmation
Receipt file
Clearing
Validations
Send file
Outward
Direct Debit
(Pacs.003)
RJCT
(Rejected)
Status
Report file
(Pacs.002)
Receipt file
Set Status of
all
transactions
Individual tx
in Rejected
End
Inward file
identification
and matching
Outward
Direct Debit
File in
Complete
Details of the flow:
1. Creditor initiates Direct Debit request(s) in a pain.008 file through a feeder/channel (can be sent as
wrapped with Fndt Message).
2. GPP (creditor bank) receives the file and successfully process it using the Mass Payments flow.
3. GPP generates and sends a file containing pacs.003 direct debit requests to the AC clearing system.
4. AC clearing system validates the direct debit request. If this validation fails (on file or transaction
level), AC triggers a pacs.002 Status Report with a negative Rejected response to the creditor bank
(GPP).
5. GPP receives the pacs.002 Status Report, matches it to the original direct debit file or transactions
and sets the relevant transactions status to Rejected.
3.2.1.2.1.2 Outward DD with Partially Accepted Status Report from AC
This alternate business use case describes a negative flow in which GPP successfully triggers an
outward direct debit payment and receives a Partially Rejected Status Report from the AC clearing.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 91
AC_MP_1.2 - Outward Direct Debit via AC Clearing
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
Creditor Bank’s
GPP MP Processing
Clearing
Service
GPP Integration Clearing Gateway Debtor Bank
Incoming Customer
file (pain.008)
Can be wrapped
with Fundtech Msg
File processing
Pre-Processing
Transactions
Sub-batch
generation
Sub-batch
Completion
Customer
Acknoledge
ment
Individual tx
in Wait
Confirmation
Receipt file
Clearing
Validations
Send file
Outward
Direct Debit
(Pacs.003)
RJCT
(Rejected)
Status
Report file
(Pacs.002)
Receipt file
Set Status of
all
transactions
Individual tx
in Rejected
End
Inward file
identification
and matching
Outward
Direct Debit
File in
Complete
Details of the flow:
1. Creditor initiates Direct Debit request(s) in a pain.008 file through a feeder/channel (can be sent as
wrapped with Fndt Message).
2. GPP (creditor bank) receives the file and successfully process it using the Mass Payments flow.
3. GPP generates and sends a file containing pacs.003 direct debit requests to the AC clearing system.
4. AC clearing system validates the direct debit request. If this validation fails for some of the
transactions included in the direct debit request file, AC triggers a pacs.002 Status Report with a
Partially Accepted response to the creditor bank (GPP). The remaining direct debit transactions which
were validated successfully are sent by the AC clearing in a direct debit request file to the debtor
bank.
5. GPP receives the pacs.002 Status Report, matches it to the original direct debit file and sets the
status of the relevant transactions to Rejected.
6. For the file transactions which were successfully validated by AC clearing and transmitted to the
debtor bank as a direct debit request, GPP waits for a respective Debit Response from the debtor
bank.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 92
3.2.1.2.1.3 Outward DD with Success Status Report from AC and Reject Debit Response from Debtor
Bank via AC
This alternate business scenario describes a negative flow in which GPP successfully triggers an outward
direct debit payment and receives a successful Status Report from the AC clearing (optional) followed by
a Reject Debit Response from the debtor bank via the AC clearing.
AC_MP_1.5 - Outward Direct Debit via AC Clearing
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
Creditor Bank’s
GPP MP Processing
Clearing
Service
GPP Integration Clearing Gateway Debtor Bank
Incoming
Customer file
(pain.008)
Can be wrapped
with Fundtech Msg
File processing
Pre-Processing
Transactions
Sub-batch
generation
Sub-batch
Completion
Outward Direct
Debit file
(Pacs.003)
Customer
Acknoledge
ment
Individual tx
in Wait
Confirmation
Receipt file
Clearing
Validations
Send file
Outward
Direct Debit
(Pacs.003)
Clearing
processing &
formatting
ACCP (Accepted) or
ACWC (Accepted With
Change)
Status Report file
(Pacs.002)
Receipt file
Direct Debit
validations &
processing
RJCT
(Rejected)
Outward Debit Response
(Pacs.002)
Clearing
Validations
& processing
Inward file
identification
and matching
Set
transaction
Status
Individual tx
in Rejected
End
RJCT
(Rejected)
Outward Debit Response
(Pacs.002)
Inward file
identification
and matching
Outward
Direct Debit
File in
Complete
Transaction
matching
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 93
Details of the flow:
1. Creditor initiates Direct Debit request(s) in a pain.008 file through a feeder/channel (can be sent as
wrapped with Fndt Message).
2. GPP (creditor bank) receives the file and successfully processes it using the Mass Payments flow.
3. GPP generates and sends a file containing pacs.003 direct debit requests to the AC clearing system.
4. AC clearing system successfully validates the direct debit transactions and may or may not trigger a
pacs.002 status report with a positive response to the creditor bank (GPP).
5. AC clearing system sends direct debit pacs.003 file to the debtor bank.
6. Debtor bank validates and processes the direct debit orders.
7. For the direct debit transactions which are rejected, debtor bank triggers a pacs.002 Debit Response
with Reject to the creditor bank via the AC clearing system.
8. GPP receives the pacs.002 Debit Response and sets the matching direct debit transactions status as
Rejected.
3.2.1.2.2 Inward Direct Debit (Debtor) from AC
Use Case Name Inward Direct Debit from AC
Actors
Debtor Bank, Banks core systems, AC clearing.
Description
This flow defines the inward direct debit MP received from AC clearing
Trigger AC clearing sends the debtor bank an inward file containing multiple direct
debit payment transactions
Pre-conditions
pacs.003 is sent from AC to the debtor bank
Post-conditions Payment is completed successfully.
A response is generated and sent to AC
Basic flow
GPP receives a file containing multiple direct debit payment transactions and
can process it successfully to complete using MP flow. GPP then successfully
triggers a debit response with a positive status to the creditor bank via AC
clearing. AC clearing sends GPP a success Status Report for the inward debit
response which was successfully validated.
Alternate flows
• Inward Direct Debit with successful outward Debit Response followed by a
successful Inward Status Report from AC
• Inward Direct Debit with Reject outward Debit Response followed by a
successful Inward Status Report from AC
3.2.1.2.2.1 Outward DD with Success Status Report from AC and Pending Debit Response from
Debtor Bank via AC
This alternate business use case describes a flow in which GPP successfully triggers an outward direct
debit payment and receives a successful Status Report from AC clearing (optional) followed by a Pending
Debit Response from the debtor bank via AC clearing.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 94
AC_MP_1.4 - Outward Direct Debit via AC Clearing
GPP User
Channel/
Initiating Party
Bank’s Core
Systems
Creditor Bank’s
GPP MP Processing
Clearing
Service
GPP Integration Clearing Gateway Debtor Bank
Incoming Customer
file (pain.008)
Can be wrapped
with Fundtech Msg File processing
Pre-Processing
Transactions
Sub-batch
generation
Sub-batch
Completion
Outward Direct
Debit file
(Pacs.003)
Customer
Acknoledge
ment
Individual tx
in Wait
Confirmation
Receipt file
Clearing
Validations
Send file
Outward
Direct Debit
(Pacs.003)
Clearing
processing &
formatting
ACCP (Accepted) or
ACWC (Accepted With
Change)
Status Report file
(Pacs.002)
Receipt file
Direct Debit
validations &
processing
PDNG
(Pending)
Outward Debit Response
(Pacs.002)
Clearing
Validations
& processing
Inward file
identification
and matching
Set
transaction
Status
Individual tx
in Pending
Debit
Confirmation
End
PDNG
(Pending)
Outward Debit Response
(Pacs.002)
Inward file
identification
and matching
Outward
Direct Debit
File in
Complete
Transaction
matching
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 95
Details of the flow:
1. Creditor initiates Direct Debit request(s) in a pain.008 file through a feeder/channel (can be sent as
wrapped with Fndt Message).
2. GPP (creditor bank) receives the file and successfully processes it using the Mass Payments flow.
3. GPP generates and sends a file containing pacs.003 direct debit requests to the AC clearing system.
4. AC clearing system successfully validates the direct debit transactions and may or may not trigger a
pacs.002 status report with a positive response to the creditor bank (GPP).
5. AC clearing system sends a direct debit pacs.003 file to the debtor bank.
6. Debtor bank validates and processes the direct debit orders.
7. For the direct debit requests in which debit accounting fails due to insufficient funds, debtor bank
triggers a pacs.002 Debit Response for Pending to the Creditor bank via AC clearing system.
GPP receives the pacs.002 Debit Response and sets the matching direct debit transactions status as
Pending.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 96
3.2.1.2.2.2 Inward DD with successful Outward DD Response
This business use case describes a positive flow in which GPP successfully processes an inward direct
debit file and sends a positive Debit Response to AC clearing. GPP then receives a successful Status
Report for this Debit Response from AC clearing indicating that the Debit Response was successfully
validated by AC.
AC_MP_2.1 - Inward Direct Debit via AC Clearing
Clearing
Service Clearing Gateway Debtor Bank’s
GPP MP Processing GPP IntegrationGPP User
Bank’s Core
Systems
Creditor Bank
Individual tx
in Complete
Clearing
processing &
formatting
Clearing
validations
ACCP (Accepted)
Status Report file
(Pacs.002)
Receipt file
Inward file
identification
and matching
Inward Status
Report file in
Complete
End
Outward
Direct Debit
file
(Pacs.003)
File processing
Pre-Processing
Transactions
Sub-batch
generation
Sub-batch
Completion
Generate Debit
Response
(Pacs.002)
Transaction
ACSC
(Accepted, Settlement
Complete)
Outward Debit Response
(Pacs.002)
ACSC
(Accepted, Settlement
Complete)
Outward Debit Response
(Pacs.002)
Receipt file
Details of the flow:
1. AC clearing triggers a Direct Debit payment instruction (pacs.003) in a file to a debtor bank.
2. GPP (debtor bank) receives the inward direct debit file and successfully processes it using the Mass
Payments flow.
3. GPP generates and sends a successful Debit Response (pacs.002) file to the AC clearing system
upon completion of the Mass Payments flow.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 97
4. AC clearing system successfully validates the inward Debit Response and triggers a pacs.002 Status
Report with a positive response to the debtor bank (GPP).
5. GPP receives the pacs.002 Status Report from AC Clearing and identifies it as a status response
received for outward debit response. No further action is performed.
3.2.1.2.2.3 Inward DD with Reject outward Debit Response followed by a successful Inward Status
Report from AC
This alternate business use case describes a negative flow in which GPP fails to successfully process an
inward direct debit transaction and sends a Reject Debit Response to AC clearing accordingly. GPP then
receives a successful Status Report for this Debit Response from AC clearing indicating that the Debit
Response was successfully validated by AC.
AC_MP_2.2 - Inward Direct Debit via AC Clearing
Clearing
Service Clearing Gateway Debtor Bank’s
GPP MP Processing GPP IntegrationGPP User
Bank’s Core
Systems
Creditor Bank
Individual tx
in Rejected
Clearing
processing &
formatting
Clearing
validations
ACCP (Accepted)
Status Report file
(Pacs.002)
Receipt file
Inward file
identification
and matching
Inward Status
Report file in
Complete
End
Outward
Direct Debit
file
(Pacs.003)
File processing
Pre-Processing
Transactions
Generate Debit
Response
(Pacs.002)
Transaction
RJCT
(Reject)
Outward Debit Response
(Pacs.002)
RJCT
(Reject)
Outward Debit Response
(Pacs.002)
Receipt file
Details of the flow:
1. AC clearing triggers a Direct Debit payment instruction (pacs.003) in a file to a Debtor Bank
2. GPP (Debtor bank) receives the inward direct debit file and processes it using the Mass Payments
flow. Some or all of the inward direct debit (pacs.003) transaction failed processing.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 98
3. For the failed transactions, GPP generates a Reject Debit Response (pacs.002) to be sent to AC
clearing system in a file.
4. AC clearing system successfully validates the inward Debit Response and triggers pacs.002 Status
Report with a positive response to the debtor bank (GPP).
5. GPP receives the pacs.002 Status Report from AC Clearing and identifies it as a status response
received for outward debit response. No further action is performed.
3.2.1.2.2.4 Inward Direct Debit Receives NSF from Accounting System
This alternate business use case describes a flow in which GPP processes an inward direct debit file and
receives an NSF response from the accounting system. GPP sends a Pending Debit Response to AC
clearing system. GPP receives a positive response indicating that the Debit Response was successfully
validated by AC.
AC_MP_2.2 - Inward Direct Debit which received an NSF Accounting response
Clearing
Service Clearing Gateway Debtor Bank’s
GPP MP Processing GPP Integration
GPP User
Bank’s Core
Systems
Creditor Bank
Outward
Direct Debit
file
(Pacs.003)
File processing
Pre-Processing
Transactions
RJCT
(Reject)
Outward Debit Response
(Pacs.002)
Posting Response NSF
D_Max_Debit_Rtry_Date>
Business Date
Posting Request (DrDebtor)
Sub Batch
Generation
Sub Batch
Completion
Yes
Accounting System
Schedule
Rejected No
Clearing
processing &
formatting
Clearing
validations
ACCP (Accepted)
Status Report file
(Pacs.002)
Receipt file
Inward file
identification
and matching
Inward Status
Report file in
Complete
End
RJCT
(Reject)
Outward Debit Response
(Pacs.002)
Receipt file
PNDG
(Pending)
Outward Debit Response
(Pacs.002)
Yes
Details of the flow:
1. AC clearing triggers a Direct Debit payment instruction (pacs.003) in a file to a debtor bank.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 99
2. GPP (debtor bank) receives the inward direct debit file and processes it using the Mass Payments
flow.
3. GPP receives an NSF response from the accounting system.
4. For the failed transactions, GPP generates a Pending Debit Response (pacs.002) to be sent to AC
clearing system in a file.
5. AC clearing system successfully validates the inward Debit Response and triggers a pacs.002 Status
Report with a positive response to the debtor bank (GPP).
6. GPP receives the pacs.002 Status Report from AC Clearing and identifies it as a status response
received for outward debit response. No further action is performed.
3.2.1.3 Outward/Inward Processing
3.2.1.3.1 Outward Direct Debit Processing
Once GPP processes the direct debit request and sends an outward direct debit pacs.003 file to AC
clearing, GPP does not set the status of the transaction to Completed, as GPP expects two confirmation
responses from AC clearing:
• Status Report – first confirmation message indicating the outcome of the direct debit request
validation in AC
• Debit Response – second confirmation message indicating a positive or negative result of the debit
requests process by the debtor bank
When there is a successful flow, during the completion stage of the direct debit Mass Payments process,
GPP sets a Wait Confirmation status to the pacs.003 transactions.
Wait Confirmation status is in the Waiting message status group. It is enabled by setting the
Communication preferences MOP attribute to Wait Confirmation.
Note: Communication preferences MOP attribute values which are supported for mass payments are
None and Wait Confirmation. Other valid values should not be set for batch based MOPs.
3.2.1.3.1.1 Inward Status Report and Debit Response Initial Processing
For outward direct debit scenarios:
1. GPP receives a pacs.002 Status Report and Debit Response confirmation messages from AC
clearing.
2. Upon receiving each of the messages, GPP identifies the pacs.002 type (Status Report or Debit
Response) and performs a matching check to the respective direct debit file or message.
3. When the matching direct debit file or transaction is found, GPP analyzes the status received in the
pacs.002 file or transaction and handles the respective direct debit status accordingly.
4. Upon receiving the pacs.002 file, as part of incoming file handling step, once the file is verified by
GPP, GPP identifies the pacs.002 type as follows.
Message Usage Service Identification
Code GPP Identification of
pacs.002
Debit request Status Reports from AC
clearing to creditor banks ST002 Status Report
Direct debit responses from AC clearing to
creditor banks DROUT Debit Response
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 100
3.2.1.3.1.2 Inward Status Report
AC sends the Status Report file (pacs.002) with an indication of the group level Message ID as exist in
the original direct debit request file. When GPP receives this file, GPP performs matching checks on a
group (file) level using the group Message ID parameter.
GPP uses the following field as the file (group) level matching criteria:
Original File (pacs.003) Status Report File (pacs.002)
Group Message ID
(<GrpHdr><MsgId>)
Original Message ID
(<OrgnlGrpInfAndSts><OrgnlMsgId>)
• When a file match is found, GPP sets the status of the original direct debit file (pacs.003) to
Completed.
• When a file match is not found, GPP sets the status of the inward confirmation file (pacs.002) to
FileNotMatched.
• When a match is found, GPP checks that the original pacs.003 file was not already matched to
another file. If file was matched before, GPP sets the status of the inward confirmation file (pacs.002)
to FileNotMatched.
Note: Group Message ID and Original Message ID fields exist in the group header of the pacs.003 and
pacs.002 files respectively. Since there is only one group header in files being sent or received from AC,
the fields indicated in the group header provides data in the level of the entire file.
3.2.1.3.1.2.1 Status Report with Accepted or Accepted with Change Status
Additional handling of the Inward Status Report (pacs.002) when the status is Accepted or Accepted with
Change.
• GPP checks the group level status of the inward pacs.002 file indicated in the
<OrgnlGrpInfAndSts><GrpSts> tag of the file group header.
o When the direct debit file (pacs.003) is validated successfully by AC clearing, the group level
status is Accepted Customer Profile (GrpSts is ACCP), in the group header of the inward Status
Report from AC clearing.
o When the direct debit file (pacs.003) is validated successfully by AC clearing but the requested
value date (action date) of one or all of the transactions is a non-working day for the debtor bank,
the group level status (<OrgnlGrpInfAndSts><GrpSts> tag) is Accepted with Change (GrpSts is
ACWC), in the group header of the inward Status Report. This status is sent to the creditor bank
as an informational message. The creditor bank is not required to perform any amendment to the
related direct debit transactions, as GPP considers the Accepted with Change status as a full file
accept (Accepted Customer Profile).
• When the file status is Accepted Customer Profile or Accepted with Change, the status of the
individual direct debit transactions related to this file remain as Wait Confirmation, until GPP receives
the Debit Response from the debtor bank via AC clearing.
Note: The Status Report received from AC clearing only includes information of rejected transactions.
Hence, in the case of full file accept, the inward pacs.002 file does not include any transaction
information.
3.2.1.3.1.2.2 Status Report with Rejected Status
Additional handling of the Inward Status Report (pacs.002) when the status is Rejected by AC clearing.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 101
• When the direct debit (pacs.003) is rejected by AC clearing, the group level status is Rejected
(<OrgnlGrpInfAndSts><GrpSts> is RJCT), in the group header of the inward Status Report.
• When GPP receives this file Reject status, as part of the inward pacs.002 file processing, GPP sets
the status of all direct debit transactions of the matched pacs.003 file to Rejected.
3.2.1.3.1.2.3 Status Report with Partially Accepted Status
Additional handling of Inward Status Report (pacs.002) when the status is Partially Accepted by AC
clearing.
• When the transactions in the direct debit file (pacs.003) were rejected by AC clearing, the group level
status is Partially Accepted (<OrgnlGrpInfAndSts><GrpSts> is PART) in the group header of the
inward Status Report.
• For the transactions received in the inward pacs.002 Status Report, GPP sets the status of the
matched pacs.003 transactions to Rejected.
• The status of the direct debit transactions which are not indicated in the pacs.002 file remain as Wait
Confirmation.
3.2.1.3.1.3 Inward Debit Response
GPP may receive an inward Debit Response from the debtor bank, following a successful Status Report
from AC clearing or when no Status Report was received from AC clearing.
The Debit Response file includes responses for all direct debit transactions which are sent in one or more
files from GPP (both successful and unsuccessful debits are included in the file).
• When the inward pacs.002 is identified as a Debit Response (Service Identification Code is DROUT),
GPP performs matching checks for each transaction included in the inward pacs.002 file.
• GPP de-bulks the inward Debit Response pacs.002 file and processes each of its transaction
individually. This process includes a matching check for this transaction to the original direct debit
transaction. This matching check is done according to the system setup of matching check rules for
AC payments.
The matching index criteria for transaction level matching check uses the following parameter:
Original Message (pacs.003) Debit Response Message (pacs.002)
Transaction ID
(<DrctDbtTxInf><PmtId><TxId>)
Original Transaction ID
(<TxInfAndSts><OrgnlTxId>)
• When a transaction level match is not found, the inward pacs.002 message is not kept in GPP.
3.2.1.3.1.3.1 Debit Response with Accepted Status
Additional handling of the Inward Debit Response (pacs.002) with Accepted Status.
• GPP identifies the inward confirmation message as a Debit Response (Service Identification Code is
DROUT) and matches it to its original direct debit transaction, for the transactions received with
Accepted Settlement Complete status (<TxInfAndSts><TxSts> is ACCP).
• GPP updates the status of the matched pacs.003 transaction from Wait Confirmation to Completed.
3.2.1.3.1.3.2 Debit Response with Pending Status
Additional handling of the Inward Debit Response (pacs.002) with Pending Status.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 102
• GPP identifies the transaction level status as Pending (<TxInfAndSts><TxSts> is PDNG), and the
matching direct debit transaction is set with a status of Pending Debit Confirmation.
• For each of the transactions received in the Debit Response file, GPP sets the status of the matched
pacs.003 transaction to Pending Debit Confirmation.
3.2.1.3.1.3.3 Debit Response with Rejected Status
Additional handling of the Inward Debit Response (pacs.002) with Rejected Status.
GPP identifies the transaction level status as Rejected (<TxInfAndSts><TxSts> is RJCT), and the
matching direct debit transaction is set with a status of Rejected.
For each of the transactions received in the Debit Response file, GPP triggers a pacs.002 process and
sets the status of the matched pacs.003 transactions to Rejected.
3.2.1.3.2 Inward Direct Debit Processing
3.2.1.3.2.1 Generation of Debit Response Message
For any inward direct debit (pacs.003) processed by GPP, a debit response confirmation message
(pacs.002) is generated and sent to the creditor bank via AC clearing. This confirmation message is used
to notify the creditor bank on the status of the direct debit processing.
GPP triggers the debit response upon routing the pacs.003 message to its final status.
3.2.1.3.2.1.1 Confirmation Message Process
The Generate Response Message process first determines whether a confirmation message is required
to be generated and sent to Clearing. This decision is based on the Message Type and Message Status.
• When a confirmation message is to be sent, GPP performs the following:
o Determines the respective message format to be used.
o Creates a relation between the processed payment (pacs.003) and the generated confirmation
message (pacs.002). This relation is done in the Relation Type Original Payment^Outgoing
Response which is used for outward Responses being sent from GPP regardless of the status
(Accept or Reject) of the generated response.
• When a confirmation message is not required to be sent, GPP skips this process.
For inward direct debit transactions (Message Type) which were successfully completed (Message
Status), GPP triggers a success Debit Response in the format of pacs.002 as required by AC clearing.
When the inward direct debit fails during the pre-processing stage of the Mass Payments flow:
• GPP sets the transaction status to RJCT (Rejected) in the <TxInfAndSts><TxSts> tag of the outward
pacs.002.
• GPP populates the reason code tag which is mandatory for rejected transactions. This reason code is
populated in the <TrxInfAndSts><StsRsnInf><Rsn><Cd> tag of the outward pacs.002. GPP maps
AM09 ISO reason code as a default value.
3.2.1.3.2.1.2 Confirmation Message Mapping
Once GPP determines that a confirmation message is required to be sent to clearing with a specific
format, GPP triggers a mapping logic for this message which complies with the field format specifications
of the destination clearing.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 103
For AC clearing, this mapping includes the following:
• Setting the attributes of the pacs.002 group header as required by AC clearing. This mapping is done
according to the pacs.002 Debit Response AC format.
• Mapping specific attributes of the inward direct debit (ppacs.003) to the outward Debit Response
(pacs.002). The list of attributes to be mapped is according to AC clearing specifications for the
pacs.002 message type.
• Setting direct debit message status in the transaction status tag (<TxInfAndSts><TxSts>) of the
outward pacs.002. When the direct debit transaction is completed successfully, GPP sets the status
of the respective transaction to ACCP (Accepted).
3.2.1.3.2.2 Inward pacs.002 Type Identification
This Service Identification Code is included in the inward Status Report received from AC clearing for an
outward Debit Response sent by GPP.
Message Usage Service
Identification
Code
GPP Identification of pacs.002
Debit responses Status Reports from AC
clearing to debtor bank ST006 Status Report
3.2.1.4 Business Setup
These are the details of the required setup in GPP profiles for the Clearing Certification.
Note: For a detailed description of all the fields in the profiles, see GPP Online Help.
3.2.1.4.1 Profiles
3.2.1.4.1.1 Method of Payment Profile
A new method of payment (MOP) profile should be defined for direct debit payments being sent to or
received from AC clearing.
These are the specific attributes that need to be defined in the MOP profile for AC Clearing.
Field Value for AC
Name AC
Description MP DD MOP for AC clearing
Calendar AC_DD_MP_ZAR
Earliest Value Date 1
Note: AC clearing only supports messages being sent one day in
advance to the action date. Messages sent at any other time
(including same day) are rejected.
Latest Value Date 1
Currency ZAR
Membership Check Checked
Send outgoing message Must be selected
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 104
Field Value for AC
Processing Tab
FIN Copy Service AC
Sender/Receiver type ZANCC
Sender ID Should be populated with the bank office NCC
3.2.1.4.1.2 Bulking Profile
As part of the Out File Generation phase of the Mass Payments process, GPP collects and organizes the
transactions destined for AC clearing system into bulks based on pre-defined criteria. This criteria
includes parameters which are defined in the Bulking profile associated with the AC MOP. Grouping of
the transaction is performed on file and bulk level.
Direct debit or Debit Response transactions sent to AC clearing by GPP should be grouped in the
outward file using the bulking profile.
For outward Direct Debit (pacs.003) and outward Debit Response (pacs.002), These are the specific
attributes that need to be defined in the Bulking profile:
Field Name Value
Name
AC_DD_MP_BLK
Description Outward Direct Debit (pacs.003) and outward Debit Response
(pacs.002) to AC Clearing
Test Code
Production
File Type AC
Minimum Transactions per File 1
Maximum Transactions per Bulk 49,999
Receiver ID 210000
3.2.1.4.1.3 Cut-off Times Profile
The Cut-off Times profile defines the latest time for transactions to be processed for AC MOP. They are
for outward direct debit (pacs.003) and outward debit responses (pacs.002) messages.
For outward direct debit files, AC clearing cut-off is different for files being sent to clearing during week
days (Monday to Friday) or during weekends (Saturday, Sunday and public holidays). For weekday and
weekends, outward Debit Responses (pacs.002) must be sent to AC clearing between 23:30 of the day in
which the respective direct debit request was received and until 5:00 of the next day.
These are the specific attributes that need to be defined in the Cut-off Times profile for AC Clearing.
Weekdays Cut-off Times Profile for Outward Direct Debit (pacs.003) sent to AC Clearing
Field Name Value
Cut-off name AC_DD_MP_WDAY
Default time True
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 105
Field Name Value
Cut-off type Clearing
Time zone SAST - Time zone for aligning cut-off times
Description Clearing Cut Off for Outward Direct Debit (pacs.003) sent to AC
Clearing during weekdays (Monday to Friday)
Interim cut-off time 18:00 - Interim Cut-off time in the time zone
Final cut-off time 18:00 - Final Cut-off time in the time zone
Weekends Cut-off Times Profile for Outward Direct Debit (pacs.003) sent to AC Clearing
Field Name Value
Cut-off name AC_DD_MP_WEND
Default time True
Cut-off type Clearing
Time zone SAST - Time zone for aligning cut-off times
Description Clearing Cut Off for Outward Direct Debit (pacs.003) sent to AC
Clearing during weekends (Saturday, Sunday and public
holidays)
Interim cut-off time 13:00 - Interim Cut-off time in the time zone
Final cut-off time 13:00 - Final Cut-off time in the time zone
Weekdays and Weekends Cut-off Times Profile for Outward Direct Debit (pacs.003) sent to AC
Clearing
Debit Responses must be sent before 5:00 AM on the next day of receiving the respective direct debit
request.
Field Name Value
Cut-off name AC_DD_MP_COTPCS2
Default time True
Cut-off type Clearing
Time zone SAST - Time zone for aligning cut-off times
Description Clearing Cut-off for Outward Debit Response (pacs.002) sent to
AC Clearing during weekdays (Monday to Friday) and
weekends (Saturday, Sunday and public holidays)
Interim cut-off time 05:00 - Interim Cut-off time in the time zone
Final cut-off time 05:00 - Final Cut-off time in the time zone
3.2.1.4.1.4 Membership Profile
The AC Membership profile defines whether the participating banks are members of the clearing house.
For supporting membership the Membership required indicator on the AC MOP profile must be selected.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 106
AC identifies its member banks by their South African NCC. Hence, a membership profile should be
defined for each participating bank, its NCC and AC defined as the MOP (Member Type should be
populated automatically with ZANCC based on MOP Sender/Receiver attribute).
These are the specific attributes that need to be defined in the Membership profile for AC Clearing.
Field Name Value
MOP AC
Member type ZANCC - Automatically added based on MOP Sender/Receiver
and Additional Member Type
Member ID Select your bank’s NCC
Main BIC No Value
Type of Membership Full member - Indicates full membership in the MOP, and Member
field is disabled
3.2.1.4.1.5 Calendars Profile
A dedicated calendar should be defined for AC clearing according to its operating days.
This AC MOP calendar name should be selected in the Calendar attribute of AC MOP profile.
These are the specific attributes that need to be defined in the Calendar profile for AC Clearing.
Field Name Value
Calendar name AC_DD_MP_ZAR
Description AC clearing RAND calendar
Default calendar Unmarked
Weekend Days None - AC clearing operates 7 days a week
3.2.1.4.1.6 Accounts Profile
Suspense account should be defined to be used in the batch (customer/clearing) accounting.
These are the specific attributes that need to be defined in the Accounts profile for AC Clearing.
Field Name Value
Account Number 99999
Currency ZAR
Party code LOCALOFFICEZA1
Account Type / Subtype SUS
3.2.1.4.1.7 Identifiers Profile
The Identifiers profile setup should be implemented to define the banks’ identifier (NCC) in AC clearing.
This setup is done for a specific bank office.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 107
Field Name Value
Office Should be populated with the bank’s office
MOP AC_DD
Identifier Should be populated with the NCC used by AC to identify the
bank
Settlement Account Should be populated with the Settlement Account number of the
Banks’ office in AC
3.2.1.4.2 Rules
3.2.1.4.2.1 Clearing Cut Off Selection Rules (103)
The applicable AC Clearing Cut off profile should be selected by GPP based on the message type and
the day of the week. This should be implemented by clearing cut off selection rules according to the
following rule setup guidelines:
Rule Rule Attribute Setup Guidelines
1 AC Clearing cut off selection for outward pacs.003 during weekdays
Rule Name AC_DD_MP_COT
Attachment This rule should be attached to an office
Rule conditions
All of the following conditions should be met:
• Message type is pacs.003
• The message is outward to AC (debit MOP =
AC)
• Message is being processed on weekdays
(processing day is not Saturday or Sunday)
Action Clearing Cut off profile to be selected:
AC_DD_MP_WDAY
2 AC Clearing default cut off selection for outward pacs.003 (applicable to Saturday and
Sunday)
Rule Name AC_DD_MP_COT_DEF
Attachment This rule should be attached to an office
Rule conditions
All of the following conditions should be met:
• Message type is pacs.003
• The message is outward to AC (debit MOP =
AC)
Action Clearing Cut off profile to be selected:
AC_DD_MP_WEND
3 AC Clearing cut off selection for outward Debit Response (pacs.002)
Rule Name AC_DD_MP_COTPCS2
Attachment This rule should be attached to an office
Rule conditions All of the following conditions should be met:
•
Message type is pacs.002
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 108
Rule Rule Attribute Setup Guidelines
• The message is outward to AC (credit MOP =
AC)
Action Clearing Cut off profile to be selected:
AC_DD_MP_COTPCS2
Note: The default clearing cut-off rule for outward pacs.003 should be implemented in case the bank is
working during weekends.
3.2.1.4.2.2 MOP Bulking Profile Selection (227)
The applicable MOP bulking profile should be selected by GPP based on the type of the message to be
sent in a file to AC clearing. GPP need to select a different bulking profile for outward direct debit
(pacs.003) and for outward debit response (pacs.002). This is implemented by MOP bulking profile
selection rules according to the following rule setup guidelines:
Rule Rule Attribute Setup Guidelines
1
AC Bulking profile selection for outward pacs.003
Rule Name AC_DD_MP_BLK
Attachment This rule should be attached to an office
Rule conditions All of the following conditions should be met:
• Message type is pacs.003
• The message is outward to AC (debit MOP =
AC)
Action MOP bulking profile to be selected:
AC_DD_MP_BLK
2
AC Bulking profile selection for outward Debit Response (pacs.002)
Rule Name AC_DD_MP_BLK_PCS2
Attachment This rule should be attached to an office
Rule conditions All of the following conditions should be met:
• Message type is pacs.002
• The message is outward to AC (credit MOP =
AC)
Action MOP bulking profile to be selected:
AC_DD_MP_BLK_PCS2
3.2.1.4.2.3 Out Bulk Grouping ID Selection (138)
GPP invokes Out Bulk Grouping ID Selection rules to determine the data manipulation profile that the
system uses to build an Out File Group ID (OFID) and Out Bulk Group ID (OGID).
The system generates and uses the OFID to place transactions into the appropriate outgoing file.
The system generates and uses the OGID to place transactions with common attributes into appropriate
groups in the outgoing file.
This should be implemented by Out Bulk Grouping ID Selection rules according to the following rule setup
guidelines:
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 109
Rule Rule Attribute Setup Guidelines
1 Outgoing group ID for outward Direct Debit (pacs.003) sent to AC
Rule Name AC_DD_MP_GRP
Attachment This rule should be attached to the outward direct
debit (pacs.003) bulking profile (AC_DD_MP_BLK)
Rule conditions None
Action Data Manipulation profile to be selected:
AC_DD_MP_GRP
2 Outgoing group ID for outward Debit Response (pacs.002) sent to AC
Rule Name AC_DD_MP_GRP_PCS2
Attachment This rule should be attached to the outward debit
response (pacs.002) bulking profile
(AC_DD_MP_BLK_PCS2)
Rule conditions None
Action Data Manipulation profile to be selected:
AC_DD_MP_GRP_PCS2
3.2.1.4.2.4 Bulking Sending Time (137)
GPP is obligated to send Debit Response files between 23:30 and 5:00 of the next date for all inward
direct debit requests (pacs.002) received during the day. Therefore, the sending time of outward Debit
Response should be set to 23:30. This is implemented by a business setup of Bulking sending time rule
with the following setup guidelines:
Rule Attribute Setup Guidelines
Rule Name AC_DD_MP_PCS2^23:30
Attachment This rule should be attached to the outward debit response (pacspacs.002)
bulking profile (AC_DD_MP_PC2)
Rule conditions None
Action Sending Time profile to be selected: AC_DD_MP_PCS2^23:30
3.2.1.4.2.5 MOP Selection Rules (3)
For outward direct debit (pacs.003) with settlement currency of ZAR, AC clearing should be selected as a
candidate to be a destination MOP. This is implemented by MOP selection rule with the following setup
guidelines:
Rule Attribute Setup Guidelines
Rule Name AC_DD_MP_OUT
Attachment This rule should be attached to an office
Rule conditions All of the following conditions should be met:
Message settlement currency is ZAR
Original Message Type is pain.008
The message is outward from GPP (credit MOP is different to BOOK)
Action MOP to be selected: AC
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 110
For inward direct debit (pacs.003) received from AC clearing, BOOK should be set as the destination
MOP of the payment. This is implemented by MOP selection rule with the following setup guidelines:
Rule Attribute Setup Guidelines
Rule Name AC_DD_MP_IN
Attachment This rule should be attached to an office
Rule conditions All of the following conditions should be met:
Message type is pacs.003
The message received from AC clearing (credit MOP is AC)
Action MOP to be selected: BOOK
3.2.1.4.2.6 Compliance Validation Skip (21)
GPP should skip compliance validation as part of the AC payment processing. This is achieved by a
business setup of Compliance Validation rule with the action of bypass. This rule should be defined with
the following setup guidelines:
Rule Attribute Setup Guidelines
Rule Name AC_DD_MP_DEF_COMP_PASS
Attachment This rule should be attached to an office
Rule conditions One of the following conditions should be met:
Message has a source Mop of AC (credit MOP is AC)
OR
Message has a destination MOP of AC (debit MOP is AC)
Action Compliance validation should be skipped (BYPASS)
3.3 Mass Payment APAC Clearing
3.3.1 Malaysia - IBG
3.3.1.1 Overview
Malaysia IBG (Interbank GIRO) is a delayed fund (not real-time processing) clearing system introduced
by MyClear (Malaysian Electronic Clearing Corporation).
This system allows electronic funds transfers between IBG-participating Financial Institutions (FIs) within
Malaysia. Consumer funds can be securely transferred from an FI account (savings, checking,
loan/financing or credit card) to an account at another FI by:
• Ensuring that only FIs that offer IBG send and receive funds via IBG
• Enabling consumers to perform IBG transfers through these channels:
o FI Branch
o Internet Banking
o ATM
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 111
• Providing unsuccessful transfer status to the consumer via an SMS (Short Messages Service) text
message that notifies the consumer of a rejected transaction via their mobile phone number
IBG also enables businesses and billing organizations (Biller), such as insurance or utility companies, to
automatically withdraw recurring payments directly from a consumer’s FI account (Payer) via multiple FIs
(Payer FI) with a single authorization.
To perform these transactions, IBG collects batch files from the Biller FIs (for example, bills, fees,
invoices) and validates and processes a payment prior to distributing it to the corresponding Payer FIs.
IBG DD (Direct Debit) offers:
• Security and control: To become a DD Biller, each business or organization must register as a
merchant with any participating Biller Bank that provides DD services. Biller Banks verify and approve
DD Biller’s Merchant Registration Forms, and assign a new Biller ID to the DD Biller.
• Direct Debit Authorization (DDA): DDA is the authorization or mandate given by the Payer to the Biller
to initiate the IBG DD or Collection transactions on a recurring basis. This is a one-time process for
each mandate before the first debit transaction sent by the Biller. Businesses may determine when
and how much to debit their customers once a direct debit mandate is obtained from the Payer.
• Direct Debit Transaction (DDT): DDT is the process of initiating and receiving payment to a debit
request. It involves Biller sending debit transactions (DDI) to Biller Banks for Payer Banks to debit
pre-approved accounts. It is a batch processing whereby all Participants (i.e. Biller Banks and Payer
Banks) submit transactions in batch files at processing windows. Similarly, Payer Bank’s responded
with the debiting status to the Biller Bank using batch files.
Additional information related to IBG:
Value
Currency code
MYR
SWIFT Service Identifier code IBG
Service type SW IFT V-Topology Messaging Scheme
Operating hours Vary depending on transaction; see Operating Hours
Cut-off times Vary depending on transaction; see Operating Hours
Maximum default (per day) IBG
Transfer Amount (MYR)
Branch: 500,000
Internet/Mobile Banking: 5,000
ATM: 5,000
3.3.1.1.1 Operating Hours
IBG abides by these operating hours and cut-off times, which vary for weekdays (Monday to Friday) and
Saturday, Sunday and Public Holidays:
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 112
3.3.1.1.2 High Level Business Flow
The flow shows the end-to-end business flow of direct debit requests and confirmation messages being
sent between the creditor bank (Biller), IBG Clearing and debtor bank (Payer).
Biller Bank
Payer
Biller
Payer Bank
DDI
DDS
DDA DMS
IBG System
IBG DD Txn
(Debit Normal)
IBG DD Txn
(Debit Return)
5. IBG DD Txn
(Debit Normal)
IBG DD Txn
(Debit Return)
1. Biller Registration
3. Biller register Payer’s DDA in DDA DMS via Biller Bank
2. Payer authorize DD
instruction to Biller
2. Payer authorize DD
instruction to Biller
Mandates
4. DDA Approval
3.3.1.1.3 Supported Message Types
IBG DD supports NACHA format, including direct debit message and its normal or return response.
Message Type Description
pain_008 Biller sends pain.008 version 2 for IBG DD collections.
NACHA_DD
(Debit Normal (DN)
MyClear NACHA supports bit collection and distribution files for
NACHA collections.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 113
Message Type Description
Transaction Code 27
NACHA_RTN
(Debit Return (DR)
MyClear NACHA supports collection and distribution files for
NACHA returns.
Transaction Code 26
Note: DNs and DRs are included in the same NACHA file. Separate NACHA files are not required for
Collections.
Debit Normal (DN)
1. The Biller Bank sends outgoing DNs to MyClear in NACHA format (Transaction code 27 in Entry
Detail Record) in the Collection file.
2. MyClear validates each DN and if valid, forwards each DN to the Payer Bank in the Distribution file.
3. The Payer Bank, upon receiving the incoming DNs, debits the Payer’s account and provides a
response to MyClear in the next IBG DD processing window in the Collection file.
Debit Return (DR)
1. A Debit Return transaction initiates in response to an outgoing DN’s request from the Biller Bank.
2. MyClear or Payer Bank initiates a DR.
The DR contains return reason codes (provided by MyClear) that are specific for MyClear and Payer
Banks.
Note: For a listing of return reason codes and their descriptions, see Appendix A: MyClear IBG
Return Reason Codes.
3.3.1.2 IBG Use Cases
Basic Use Case Alternate Use Case
Inward/Outward
Processing Outward DD Receiving a Successful Response from IBG
Outward DD Receiving a Negative Response from IBG
Outward DD Received with Future Date from Biller
Outgoing DD Failed Pre-processing at Biller Bank
Inward Direct Debit
(Payer) from IBG Inward DD with Successful Outgoing DR
Inward DN Failed Mandate Validation Returns Outgoing DR (R99)
response
Incoming DN with Debit-Retry requested scheduled for next day retry
Incoming DN with Insufficient Funds Generates Outgoing DR
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 114
3.3.1.2.1 Outward Direct Debit (Biller) to IBG
3.3.1.2.1.1 Outward DD Receiving a Successful Response from IBG
This use case describes the flow that initiates when the Biller (Creditor) submits a pain.008 Collection file.
GPP generates an Outward DN, and a successful response is received in the Incoming DR within the
appropriate time frame.
1. The individual direct debit transaction is sent to IBG as an Outgoing DN in the Collection file.
2. Upon receiving the successful Incoming DR for corresponding Outgoing DN in the Distribution file, the
DNs processes to Complete.
3. GPP credits the Biller (lump sum or itemized) for all successful Collections upon receiving a DR with
Return Reason Code R00 (received per window per original incoming pain.008 file).
Details of the flow:
1. GPP (as Biller Bank) receives a pain.008 from Biller that contains multiple Collection requests from a
different Payer.
Note: The Payer’s account is either held with the Biller Bank or with another bank.
2. GPP parses the pain.008 as per the standard mass payment process.
3. GPP creates a File Summary and Batch Summary record.
4. GPP creates individual pain.008 transactions and is processed as per standard mass payment
business flow – Outgoing DD transactions.
5. GPP assigns MYIBGDD MOP for individual Outgoing DD transactions.
6. The transaction converts to NACHA_DD transaction after MOP selection.
7. A bulking profile is assigned to each transaction.
8. GPP creates the Outgoing DN in NACHA format and stores it in Out_File_Buffer table. The file
proceeds to the Wait Confirmation queue.
9. Upon receiving the Incoming DR in the next Distribution window, GPP attempts to match Incoming
DR with the existing Outgoing DN in the Wait Confirmation queue.
10. After successful matching of Incoming DR with R00:
a. Outgoing DN is sent to Complete queue from the Wait Confirmation queue.
b. Incoming DR proceeds further in workflow.
c. GPP uses Incoming DR with R00 return code (X_RSN_CD = R00) to generate an S message.
Note: An S message uses the online posting interface to perform the clearing side posting.
d. Incoming DR is processed to the Complete queue.
11. GPP credits the Biller using a timer-based task.
a. The task triggers at the end of IBG window.
b. The task either:
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 115
Performs lump sum
Performs an itemized credit to Biller for all successful returns (DR R00) received per window
per original pain.008 file received from Biller.
This diagram shows the end-to-end business flow of direct debit message and its response.
IBG Direct Debit Transaction
My ClearBiller Biller Bank Payer Bank Payer
Phase
Submit DDI File
Start
Credit Biller
Account
Complie and
Generate IBG File
1
DDI
IBG System
2
IBG DD File
(DN)
5
Status
(DR)
Mandate Checking
and Debit Payer
3
Distribute
(DN)
4
Status
(DR)
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 116
3.3.1.2.1.2 Outward DD Receiving a Negative Response from IBG
This use case invokes when IBG sends an Incoming Distribution File which contains a negative DR
(Return Reason Code <> R00) for an outgoing DN (submitted in a previous Outgoing Collection Files).
GPP performs the matching process, and after making a successful match, GPP rejects the matched
Outgoing DN. GPP then processes the Incoming DR to the Complete queue.
Note: An R99 return reason code (any return code other than R00) represents an error.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 117
Outgoing DN to MyClear from Biller Bank – Incoming DR R99 response – IBGDD-DDO-DN-3.1.2
Channel/
Initiating Party MyClear
GPP (Biller Bank) GPP Clearing
Integration
GPP Integration Bank’s Core SystemGPP User
Phase
Pain.008
Pre-processing
(Individual
Transactions -
DN)
Sub Batch
Completion –
Execution
Individual
Send File
Clearing
Processing and
Formatting
Outgoing
Collection
file (NACHA)
Collection File
(Out DN)
In File
Processing
Sub Batch
Completion –
Execution
Bulking Profile
(I)
Out File
Generation Out DN
Receive File Distribution File
(In DR)
In File
Processing In DR – R99
Matching IN
DR with Out
DN
Sub Batch
Completion –
Execution
Individual
Receive File
Pain.008
Complete
Wait
Confirmation
Cancel
Rejected
After Match DR R99
Pre-processing
(Individual
Transactions -
DR)
Details of the flow:
This business scenario describes the process of receiving pain.008 and generation of Outgoing DN.
1. The corresponding Incoming DR R00 response is received in next distribution file. GPP receives an
Incoming Distribution File with DR R99 (Return Reason Code <> R00) response.
2. GPP performs the matching of Incoming DR with existing Outgoing DN waiting in the Wait
Confirmation queue as per Incoming DR.
3. After successful matching of Incoming DR without R00:
a. Outgoing DN is sent to the Rejected queue from the Wait Confirmation queue.
b. Incoming DR is processed to the Complete queue.
3.3.1.2.1.3 Outward DD Received with Future Date from Biller
This use case invokes when the Biller (Creditor) submits the pain.008 Collection with future value date.
Note: IBG DD Collections are warehoused in GPP until next value date, and are processed only on the
value date.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 118
Outgoing DN (future dated) from Biller –
IBGDD-DDO-DN-3.1.3
Channel/
Initiating Party MyClear
GPP (Biller Bank) GPP Clearing
Integration
GPP Integration Bank’s Core SystemGPP User
Phase
Pain.008
Pre-processing
(Individual
Transactions -
DN)
In File
Processing
Receive File
Pain.008
Schedule
Future Date
VD > BD
Details of the flow:
This business scenario describes the process of receiving pain.008 received with future dated Collections
from Biller.
1. GPP receives pain.008 from Biller Bank.
2. GPP parses the pain.008 file as per standard mass payment flow.
3. For pain.008 with Requested Collection Date in future (VD > BD), GPP warehouses the payment in
the Schedule queue with IBGDD MOP’s Latest Value Date setting = 0 (with appropriate audit as per
BAU (Business As Usual)).
4. Using existing Release from Schedule queue task, GPP processes the Outgoing DN on value date
and sends the DN to MyClear.
3.3.1.2.1.4 Outgoing DD Failed Pre-processing at Biller Bank
This use case invokes when the Biller (Creditor) submits a pain.008 Collection that fails pre-processing at
GPP.
Note: GPP automatically rejects a pain.008 Collection. A rejected pain.008 is not sent to MyClear for
collection.
Outgoing DN (failed pre-processing) from Biller –
IBGDD-DDO-DN-3.1.4
Channel/
Initiating Party MyClearGPP (Biller Bank) GPP Clearing
Integration
GPP Integration Bank’s Core SystemGPP User
Phase
Pain.008
Pre-processing
(Individual
Transactions -
DN)
In File
Processing
Receive File
Pain.008
Rejected
Failed
Details of the flow:
This business scenario describes the process of receiving pain.008 with future-dated Collections from
Biller.
1. GPP receives pain.008 from Biller.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 119
2. GPP parses the pain.008 file as per standard mass payment flow.
3. If pain.008 fails following validations during pre-processing, GPP automatically processes the file to
the Rejected queue with the relevant error message and audit trail.
o 1st in Debit Party Identification failed, Debtor agent is not identified (either missing setup or
invalid routing number).
o 1st in Credit Party Identification failed, Creditor agent is not identified (either missing setup or
invalid routing number).
o MOP Selection failed, Debtor agent is not member of MYIBGDD MOP.
o Target MOP STP Validation failed, Invalid Debtor Account Type, Biller Code, Biller Name and
Debit-Retry is received not correct format in Unstructured Remittance Information field or Debit-
Retry received is greater than 4.
3.3.1.2.2 Inward Direct Debit (Payer) from IBG
Use Case Name Incoming Direct Debit [DN – Debtor Side]
Actors MyClear IBG DD, Payer Bank, Bank’s core systems, Payer
Description This flow defines the incoming DN (Debit Normal, Collection) to Payer Bank’s
received via MyClear.
Trigger MyClear sends the NACHA Distribution file containing incoming DNs.
Pre-conditions The NACHA file is formatted per IBG System Message Format V3.3.
Post Condition NACHA Debit Return transaction is generated as a response to Incoming
Debit Normal.
Basic successful
flow GPP as Payer Bank receives an incoming direct debit Collection message
[Inward DN] from MyClear.
• After successful mandate checking, GPP debits the PAYER’s account.
• After successful debit, GPP provide a successful response DR (R00) to
MyClear.
Negative Flows • Inward DN Failed Mandate Validation Returns Outgoing DR (R99)
response
• Incoming DN with Debit-Retry Requested Scheduled for Next Day Retry
• Incoming DN with Insufficient Funds Generates Outgoing DR (R99)
• Incoming DN Manual Reject Outgoing DR R99
3.3.1.2.2.1 Inward DD with Successful Outgoing DR
This business scenario invokes when GPP receives an inward direct debit (Incoming DN) instruction.
Debit Return (DR) is generated and then sent to IBG.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 120
Details of the flow:
This business scenario describes the process for generating Outgoing DR [NACHA_RTN].
1. GPP (as Payer Bank) receives Inward DN IBG DD transaction [NACHA format] from MyClear.
2. GPP parses the NACHA format into NACHA XML and assigns message type as NACHA_DD.
3. GPP processes the NACHA_DD as per the standard mass payment flow.
4. GPP performs the mandate checking as per Mandate Validation.
5. After successful mandate checking, GPP debits the Payer’s account.
6. After successful debit to Payer’s account, GPP:
o Updates the mandate. See Mandate Validation for more information.
o Sends Incoming DN (NACHA_DD) to the Complete queue.
o Generates Outgoing DR (NACHA_RTN) with return code R00.
o Sends Outgoing DR to Complete queue.
7. FT Standard Advice is generated and sent to the Payer for notification about successful debit against
Collection.
8. Outgoing DRs are delivered to MyClear in next available window Outgoing Collection File.
3.3.1.2.2.2 Inward DN Failed Mandate Validation Returns Outgoing DR (R99) response
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 121
This business scenario invokes when a mandate validation fails for an Incoming DN from MyClear to the
Payer Bank.
Details of the flow:
1. GPP rejects the Incoming DN and generates an Outgoing DR with the appropriate Return Reason
Code.
2. GPP (as Payer Bank) receives Inward DN IBG DD transaction [NACHA format] from MyClear.
3. GPP parses the NACHA format into NACHA XML and assigns message type as NACHA_DD.
4. GPP processes the Incoming DN (NACHA_DD) as per the standard mass payment flow.
5. GPP performs mandate checking. See Mandate Validation for more information.
6. Incoming DN (NACHA_DD) fails mandate validation.
7. GPP sends Incoming DN to the Rejected queue.
8. GPP generates an Outgoing DR with return codes R99 [X_RSN_CD] for all mandate validation
failure. See Mandate Validation for more information.
9. Outgoing DR is processed to the Complete queue.
3.3.1.2.2.3 Incoming DN with Debit-Retry requested scheduled for next day retry
This business scenario describes the process for insufficient funds response handling while attempting to
debit debtor’s account.
• GPP invokes when Payer (Debtor) has insufficient funds and biller has requested for the Debit Retry
on Payer’s account for a certain number of days.
• GPP generates FT Standard Advice to notify the Payer to top up the debit account so that funds can
be debited next day.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 122
Incoming DN from MyClear to Payer Bank – Debit Retry Scheduled – No response to MyClear - IBGDD-DDI-DN-3.2.3
Bank’s Core SystemMyClear GPP UsersGPP Clearing Services GPP MP Processing Payer
Phase
Incoming
Distribution
file (NACHA)
Receives File
Accounting System
Posting Successful ?
Posting Response
D_Max_Debit_Rtry_Date >
Business Date
NSF response
Schedule
Posting Request (Dr Payer)
In File
Processing
Pre-processing
(Individual
Transactions -
DN)
Sub Batch
Completion –
Execution (I)
Sub Batch
Completion –
Execution
Individual
Yes
Payer
FT Std Advice for next day retry
[Termination Flow]
D_Debit_Rtry_Days mapping
D_Max_Debit_Rtry_Date calculation
Mandate Checking
Hold until time (optional)
Details of the flow:
1. GPP receives Inward Distribution NACHA file from MyClear.
2. GPP parses the Incoming NACHA file and creates NACHA_DD transactions for Incoming DN
transactions. These transactions are processed as per GPP Mass Payment Flow.
3. GPP extracts the Debit-Retry from Incoming DN to the derived field D_Debit_Rtry_Days using STP
Mapping Selection rules.
4. GPP performs mandate validation on pacs.003 as per IBG DD specifications.
5. After successful mandate checking, GPP sends the posting request to debit the payer’s account.
6. For NSF response, GPP processes the payment as follows:
a. GPP sends the Incoming DN to Schedule queue if debit retry is applicable.
b. GPP sends the FT Standard Advice to Payer about next day debit retry. Using this advice,
PAYER may top up their account.
Note: GPP does not handle IBG R16 (Account Frozen: funds unavailable due to specific action by
the RDFI or by legal action) and R20 (No-Transaction Account: ACH entry is destined for a non-
transaction account) return codes.
The decision for debit retry based on these errors is determined by the customer. The Debit Retry
value has no effect if an account has been successfully debited in the first attempt.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 123
3.3.1.2.2.4 Incoming DN with Insufficient Funds Generates Outgoing DR
This business scenario invokes when the Payer’s account cannot be debited due to insufficient funds
(even after trying for number of days as per Debit-Retry, if applicable). GPP generates Outgoing DR
(R01) to MyClear and rejects the Incoming DN.
Details of the flow:
1. GPP receives an Inward Distribution NACHA file from MyClear.
2. GPP parses the Incoming NACHA file and creates NACHA_DD transactions for Incoming DN
transactions. These transactions are processed as per GPP Mass Payment Flow.
3. GPP performs mandate validation on pacs.003 as per IBG DD specifications.
4. GPP attempts to debit the PAYER after successful mandate checking.
5. For NSF response (after exceeding number of Debit-Retries, if applicable):
o GPP sends the Incoming DN to Rejected queue.
o GPP generates an Outgoing DR with R99 response [X_RSN_CD].
o GPP sends an Outgoing DR to the Complete queue.
Note: The Payer is not advised for insufficient funds rejects.
3.3.1.2.3 Outgoing Debit Normal [DN – Biller Side]
The user can click Cancel to cancel any Outgoing DN not yet sent out to IBG DD from Wait Confirmation
queue. The cancellation would be allowed only until if the Outgoing DN has not been sent to clearing in
the Outgoing (Distribution) File as per it’s bulk sending time.
Note: The ACK/Confirmation button does not display in the Wait Confirmation queue for IBG DD outgoing
DN.
Upon cancellation of an Outgoing DN, GPP sends the Collection to Approve Cancel queue. Until the
Collection is no longer included in the Outgoing File, the Approve Cancel queue can either:
• Approve Cancel
• Refuse
If a Collection has been sent, but is not yet approved, the Approve Cancel option does not display. The
user can click Refuse to stop the cancellation request. This action sends the Collection to the Wait
Confirmation queue.
3.3.1.2.3.1 Outgoing DN with Incoming DR R00 (success) within Time Frame
This business scenario invokes when a Biller (Creditor) submits a pain.008 collection file. Individual direct
debit transactions are sent to IBG DD for collection as an Outgoing DN in Collection file. DNs process to
Complete when a successful Incoming DR is received for a corresponding Outgoing DN.
GPP credits the biller (lump sum or itemized) for all successful collections (upon receiving DR with Return
Reason Code = R00) received per window per original incoming pain.008 file. Upon receiving this file, the
pain.008 processes via standard mass payment process. The pain.008 is recorded in File Summary and
Batch Summary as per BAU.
The following diagram highlights the steps that are relevant for pain.008 processing and interaction with
IBG DD.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 124
Outgoing DN to MyClear from Biller Bank – Incoming DR R00 response –
IBGDD-DDO-DN-3.1.1
Channel/
Initiating Party MyClearGPP (Biller Bank) GPP Clearing
Integration
GPP Integration Bank’s Core SystemGPP User
Phase
Pain.008
Pre-processing
(Individual
Transactions -
DN)
Sub Batch
Completion –
Execution
Individual
Send File
Clearing
Processing and
Formatting
Outgoing
Collection
file (NACHA)
Collection File
(Out DN)
In File
Processing
Sub Batch
Completion –
Execution
Bulking Profile
(I)
Out File
Generation Out DN
Receive File Distribution File
(In DR)
In File
Processing In DR – R00
Matching IN
DR with Out
DN
Sub Batch
Completion –
Execution
Individual
Receive File
Pain.008
Posting Task Accounting System
Batch Posting
Dr BSA
Cr Biller
(Lump sum/Itemized)
Complete
Wait
Confirmation
Cancel
Sub Batch
Generation (S)
Accounting System
Online Posting (S)
Dr Clearing (lump sum)
Cr BSA (lump sum)
Complete
After Match DR R00
Pre-processing
(Individual
Transactions -
DR)
Details of the flow:
This business scenario describes the process of receiving pain.008 and generation of Outgoing DN. The
corresponding Incoming DR is received in next distribution file.
1. GPP as Biller Bank receives pain.008 from Biller containing multiple collection request from different
payer. Payer’s account is either held with Biller Bank or with another bank.
2. GPP parses the pain.008 as per standard mass payment process.
3. GPP creates File Summary and Batch Summary record.
4. GPP creates individual pain.008 transactions and processes each as per standard mass payment
business flow – Outgoing DD transactions.
5. GPP assigns MYIBGDD MOP for these individual Outgoing DD transactions.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 125
Note: The transaction is converted to NACHA_DD transaction after MOP selection. A bulking profile
is assigned to each transaction.
6. The Outgoing DN is created in NACHA format and stored in Out_File_Buffer table.
7. The Outgoing DN processes to the Wait Confirmation queue.
8. Upon receiving the Incoming DR in next Distribution window, GPP attempts to match Incoming DR
with existing Outgoing DN in Wait Confirmation queue.
9. After successful matching of Incoming DR with R00,
a. Outgoing DN is sent to Complete queue from Wait Confirmation queue.
b. Incoming DR proceeds further in the workflow.
c. S message is generated using Incoming DR with R00 return code (X_RSN_CD = R00).
d. S message perform the clearing side posting using online posting interface.
e. Incoming DR is processed to the Complete queue.
10. GPP credits the biller using a timer-based task.
Note: This task triggers at the end of IBG window, and performs either a lump sum or itemized credit
to Biller for all successful returns (DR R00) received per window per original pain.008 file received
from Biller.
3.3.1.2.3.2 Outgoing DN Receives Negative DR (R99) from MyClear or RFI
This business scenario invokes when MyClear sends the Incoming Distribution File containing the
negative DR (Return Reason Code <> R00) for an outgoing DN submitted in previous Outgoing
Collection Files.
o GPP performs the matching and after successful match, GPP rejects the matched Outgoing DN.
o GPP process the Incoming DR to the Complete queue.
Note: An R99 return reason code (any return code other than R00) represents an error.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 126
Outgoing DN to MyClear from Biller Bank – Incoming DR R99 response –
IBGDD-DDO-DN-3.1.2
Channel/
Initiating Party MyClearGPP (Biller Bank) GPP Clearing
Integration
GPP Integration Bank’s Core SystemGPP User
Phase
Pain.008
Pre-processing
(Individual
Transactions -
DN)
Sub Batch
Completion –
Execution
Individual
Send File
Clearing
Processing and
Formatting
Outgoing
Collection
file (NACHA)
Collection File
(Out DN)
In File
Processing
Sub Batch
Completion –
Execution
Bulking Profile
(I)
Out File
Generation Out DN
Receive File Distribution File
(In DR)
In File
Processing In DR – R99
Matching IN
DR with Out
DN
Sub Batch
Completion –
Execution
Individual
Receive File
Pain.008
Complete
Wait
Confirmation
Cancel
Rejected
After Match DR R99
Pre-processing
(Individual
Transactions -
DR)
Details of the flow:
This business scenario describes the process of receiving pain.008 and generation of Outgoing DN. The
corresponding Incoming DR R00 response is received in next distribution file.
1. GPP receives an Incoming Distribution File with DR R99 (Return Reason Code <> R00) response.
2. GPP performs the matching of Incoming DR with existing Outgoing DN waiting in the Wait
Confirmation queue.
3. After successful matching of Incoming DR without R00,
a. Outgoing DN is sent to the Rejected queue from the Wait Confirmation queue.
b. The Incoming DR processes to the Complete queue.
3.3.1.2.3.3 Outgoing DN Received with Future Date from Biller
This business scenario invokes when the Biller (Creditor) submits the pain.008 collection with a future
value date. IBG DD collections are warehoused in GPP until the next value date, they are processed only
on the value date.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 127
Outgoing DN (future dated) from Biller –
IBGDD-DDO-DN-3.1.3
Channel/
Initiating Party MyClear
GPP (Biller Bank) GPP Clearing
Integration
GPP Integration Bank’s Core SystemGPP User
Phase
Pain.008
Pre-processing
(Individual
Transactions -
DN)
In File
Processing
Receive File
Pain.008
Schedule
Future Date
VD > BD
Details of the flow:
This business scenario describes the process of receiving pain.008 received with future dated collections
from Biller.
1. GPP receives pain.008 from Biller.
2. GPP parses the pain.008 file as per standard mass payment flow.
3. For pain.008 with Requested Collection Date in future (VD > BD), GPP warehouses the payment in
the Schedule queue with IBGDD MOP’s Latest Value Date setting = 0 (with appropriate audit as per
BAU).
4. Using the existing Release from Schedule queue task, GPP processes the Outgoing DN on value
date and sends it to MyClear.
3.3.1.2.3.4 Outgoing DN Fails Pre-processing at Biller Bank
This business scenario invokes when the Biller (Creditor) submits the pain.008 collection that fails pre-
processing at GPP. GPP automatically rejects this type of pain.008.
Outgoing DN (failed pre-processing) from Biller –
IBGDD-DDO-DN-3.1.4
Channel/
Initiating Party MyClear
GPP (Biller Bank) GPP Clearing
Integration
GPP Integration Bank’s Core System
GPP User
Phase
Pain.008
Pre-processing
(Individual
Transactions -
DN)
In File
Processing
Receive File
Pain.008
Rejected
Failed
Details of the flow:
1. GPP receives pain.008 from Biller.
2. GPP parses the pain.008 file in the mass payment workflow.
3. If pain.008 fails the following validations during pre-processing, GPP automatically send them to the
Rejected queue with relevant error message and audit trail:
o First in Debit Party Identification failed, Debtor agent is not identified (either missing setup or
invalid routing number).
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 128
o First in Credit Party Identification failed, Creditor agent is not identified (either missing setup or
invalid routing number).
o MOP Selection failed, Debtor agent is not member of MYIBGDD MOP.
o Target MOP STP Validation failed, Invalid Debtor Account Type (not as per MyClear account type
1, 2 or 3). Biller Code, Biller Name and Debit-Retry are not received in the correct format in the
Unstructured Remittance Information field. Debit-Retry received is greater than 4.
Note: A rejected pain.008 is not sent to MyClear for collection.
3.3.1.2.4 Outgoing DN Missed DR Time Frame
An outgoing DN is waiting for the response and missed the expected time to wait for the response DR
message. In this case, it is expected to reject the outgoing DN.
Details of the flow:
1. Outgoing DN is sent to MyClear.
2. The Outgoing DN waits for the response until DR time frame. The DR time frame is either default Win
2 T+1 or as per the time frame defined by the biller in Debit Retry field.
3. GPP does not get the response within the DR time frame.
4. GPP sends the Outgoing DN to Rejected queue using a task MYIBGDD: Outgoing collection missed
response. The task tracks the DR time frame using the D_Max_Debit_Rtry_Date.
3.3.1.2.5 Incoming Debit Normal (DN – Payer Side)
Use Case Name Incoming Direct Debit (DN – Debtor Side)
Actors MyClear IBG DD, Payer Bank, Bank’s core systems, Payer
Description This flow defines the incoming debit normal (collection) to Payer Bank’s
received via MyClear.
Trigger MyClear sends the NACHA Distribution file containing incoming DNs.
Pre-conditions The NACHA file is well formatted as per IBG System Message Format V3.3.
Post Condition NACHA Debit Return transaction would be generated as a response to
Incoming Debit Normal.
Basic successful
flow
• GPP as Payer Bank receives an incoming direct debit collection message
[Inward DN] from MyClear.
• After successful mandate checking, GPP debits the payer’s account.
• After successful debit, GPP provide a successful response DR (R00) to
MyClear.
Negative Flows • Inward DN Failed Mandate Validation Returns Outgoing DR (R99)
response
• Incoming DN with Debit-Retry Requested Scheduled for Next Day Retry
• Incoming DN with Insufficient Funds Generates Outgoing DR (R99)
• Incoming DN Manual Reject Outgoing DR R99
3.3.1.2.5.1 Incoming DN with Outgoing DR R00 (success) within DR Time Frame
This business scenario is invoked when GPP receives an inward direct debit (Incoming DN) instruction.
Debit Return (DR) would be generated and send to the MyClear IBG.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 129
Details of the flow:
1. GPP (as Payer Bank) receives Inward DN IBG DD transaction [NACHA format] from MyClear.
2. GPP parses the NACHA format into NACHA XML and assigns message type as NACHA_DD.
3. GPP processes the NACHA_DD as per the standard Mass Payment flow.
GPP performs mandate checking. For more information, see Mandate Validation.
4. After successful mandate checking, GPP would debit the Payer’s account
5. After successful debit to Payer’s account, GPP:
a. Updates the mandate.
b. Sends Incoming DN (NACHA_DD) to Complete queue.
c. Generates Outgoing DR (NACHA_RTN) with return code R00.
d. Sends Outgoing DR to Complete queue.
6. FT Standard Advice is generated and sent to the Payer for notification about successful debit against
collection.
7. Outgoing DRs are delivered to MyClear in next available window Outgoing Collection File.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 130
3.3.1.2.5.2 Incoming DN Failed Mandate Validation Returns Outgoing DR (R99) Response
This business scenario invokes when mandate validations fails for an Incoming DN. GPP rejects the
Incoming DN and generates an Outgoing DR with appropriate Return Reason Code.
Details of the flow:
1. GPP (as Payer Bank) receives Inward DN IBG DD transaction [NACHA format] from MyClear.
2. GPP parses the NACHA format into NACHA XML and assigns message type as NACHA_DD.
3. GPP processes the Incoming DN (NACHA_DD) as per the standard mass payment flow.
4. GPP performs the mandate checking as described in Mandate Validation.
5. Incoming DN (NACHA_DD) fails mandate validation.
6. GPP sends Incoming DN to the Rejected queue.
7. GPP generates an Outgoing DR with return codes R99 [X_RSN_CD] for all mandate validation failure
as describes in Mandate Validation.
8. Outgoing DR processes to the Complete queue.
3.3.1.2.5.3 Incoming DN with Debit-Retry Requested Scheduled for Next Day Retry
This business scenario invokes when Payer (Debtor) has insufficient funds and the Biller has requested
for the Debit Retry on Payer’s account for a certain number of days.
GPP generates an FT Standard Advice to notify the Payer to top up the debit account so that funds can
be debited next day.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 131
Incoming DN from MyClear to Payer Bank – Debit Retry Scheduled – No response to MyClear - IBGDD-DDI-DN-3.2.3
Bank’s Core SystemMyClear GPP Users
GPP Clearing Services GPP MP Processing Payer
Phase
Incoming
Distribution
file (NACHA)
Receives File
Accounting System
Posting Successful ?
Posting Response
D_Max_Debit_Rtry_Date >
Business Date
NSF response
Schedule
Posting Request (Dr Payer)
In File
Processing
Pre-processing
(Individual
Transactions -
DN)
Sub Batch
Completion –
Execution (I)
Sub Batch
Completion –
Execution
Individual
Yes
Payer
FT Std Advice for next day retry
[Termination Flow]
D_Debit_Rtry_Days mapping
D_Max_Debit_Rtry_Date calculation
Mandate Checking
Hold until time (optional)
Details of the flow:
1. GPP receives Inward Distribution NACHA file from MyClear.
2. GPP parses the Incoming NACHA file and creates NACHA_DD transactions for Incoming DN
transactions, processed per GPP Mass Payment Flow.
3. GPP extracts the Debit-Retry from Incoming DN to the derived field D_Debit_Rtry_Days using STP
Mapping Selection rules.
4. GPP performs mandate validation on pacs.003 as per IBG DD specifications.
5. After successful mandate checking, GPP sends the posting request to debit the Payer’s account.
6. For NSF response GPP would process payment.
a. GPP would send the Incoming DN to Schedule queue if debit retry is applicable.
b. GPP would send FT Standard Advice to Payer about next day debit retry. Using this advice,
payer may top up their account.
Note: GPP does not handle the return codes IBG R16 and R20 return codes. These return codes are
related to account frozen and dormant. The decision for debit retry based on these errors varies from
customer to customer and hence GPP would not handle it at product level.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 132
3.3.1.2.5.4 Incoming DN with Insufficient Funds Generates Outgoing DR (R99)
This business scenario invokes when a PayerPs account cannot be debited due to insufficient funds
(even after trying for number of days as per Debit-Retry, if applicable). GPP generates an Outgoing DR
(R01) to MyClear and rejects the Incoming DN.
Details of the flow:
1. GPP receives Inward Distribution NACHA file from MyClear.
2. GPP parses the Incoming NACHA file and creates NACHA_DD transactions for Incoming DN
transactions, which are processed as per GPP Mass Payment Flow.
3. GPP performs Mandate Validation on pacs.003 as per IBG DD specifications.
4. GPP attempts to debit the payer after successful mandate checking.
5. For NSF response (after exceeding number of Debit-Retries, if applicable):
a. GPP sends the Incoming DN to the Rejected queue.
b. GPP generates an Outgoing DR with a response.
c. GPP sends an Outgoing DR to the Complete queue.
Note: The Payer is not advised for insufficient funds rejects.
3.3.1.2.5.5 Incoming DN Manual Reject Outgoing DR R99
GPP provides an option to manually reject the Incoming DN waiting in the Schedule queue for next day
debit retry (Incoming DN with Debit-Retry Requested Scheduled for Next Day Retry).
For IBG DD Incoming DN waiting in the Schedule queue, if the user clicks Reject, GPP:
• Sends Incoming DN to Rejected queue
• Generates Outgoing DR.
3.3.1.2.6 Manual Message Handling
No manual handling is applicable for successful Collection and Outgoing DR R00 response to MyClear.
3.3.1.2.7 Mandate Validation
3.3.1.2.7.1 Debtor Side Mandate Validation
In the Mandate profile, a UMR (Unique Mandate Reference) is a creditor-supplied identification code.
GPP uses the UMR and the CID to identify a mandate.
Note: The UMR is an identification code that can be up to 25 alphanumeric characters in length.
In GPP, the UMR maps to a Mandate Number in an IBG DD file. MyClear assigns a UMR for each DDA
form processed by MyClear. Although the Record Number field is mandatory in the mandate upload
received from MyClear, it is optional in an IBG DD NACHA file.
GPP validates incoming Collections by searching the mandate using the following criteria:
• Office (Mandate.Office – Transaction Office)
• Debtor Account (Mandate.Debtor_IBAN – Payer’s account)
• Creditor ID (Mandate.Creditor_ID – Biller ID)
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 133
• Usage (Mandate.Creditor Debtor Usage)
A mandate search must include a UMR. The search criteria Office and Usage are added by the code and
not added to the Mandate_Index_Structure and Mandate_Search_Index_Structure. Once a search
completes, MyClear determines the Mandate Number and Payment Reference Number.
Multiple mandates can be set for the same Payer account and Biller ID combination. The Payment
Reference Number is mandatory in current ENRP specification. With IBG DD scheme, mandate validation
does not consider the Payment Reference Number in the mandate index.
For more information about direct debit mandate management, validation, and enrichment, see the GPP
Business Guide Mass Payments.
3.3.1.2.7.2 Mandate Lookup Dynamic Index
GPP includes a Dynamic Index, which provides dynamic mandate lookup criteria when searching for a
direct debit mandate specific to a particular region, such as IBGDD in Malaysia. This enhancement
increases GPP’s flexibility to set Mandate search criteria per clearing/scheme.
GPP generates a unique Mandate Index for every new or updated mandate. A thorough validation
process verifies that each Mandate ID index is distinctive.
Note: The GPP Scheme MOPs table defines the dynamic mandate index that combines fields as per
scheme.
3.3.1.2.7.2.1 Mandate Frequency Fields
To manage mandate activity, users select a mandate periodicity. These frequencies are available via the
Mandate periodicity dropdown that displays in the Mandate Activity area of the Limits tab:
• Daily [DALY]
• Weekly [WEEK]
• Monthly [MNTH]
• Quarterly [QURT]
• Half Yearly [HFYR]
• Yearly [YEAR]
In addition, the following fields have been added to the Mandate Activity area of the Limits tab:
• Max frequency per period: This (optional) numeric field allows the user to enter up to 3 (three) digits.
It stores the maximum mandate frequency per mandate periodicity, for example 2 (two) times a year
(static value). This field is disabled if the Mandate periodicity field is blank. During Create mode, this
field is blank by default.
• Total number of collections per period: This field tracks and stores the total number of collections
submitted against a selected mandate per mandate periodicity (dynamic value).
3.3.1.2.7.2.2 Counter Clearing Tasks
GPP clears the counters when a mandate periodicity (frequency) ends.
To reset the Total number of collections per period to 0 (zero), use these EOD (End of Day) tasks, with 1
(one) task per mandate periodicity: (Daily, Weekly, Monthly, Quarterly, Half Year, and Year).
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 134
Periodicity Reset Mandate
RESET_MNDT_WEEKLY_COUNT
Weekly used count
RESET_MNDT_DAILY_COUNT Daily used count
RESET_MNDT_MONTHLY_COUNT
Monthly used count
RESET_MNDT_QUARTERLY_COUNT
Quarterly used count
RESET_MNDT_HALF_YEAR_COUNT
Half year used count
RESET_MNDT_YEAR_COUNT
Year used count
Note: Mandate-related tasks for counter updates must be executed before the start of the next period
(last business date).
GPP resets these dates and uses tasks to clear the counters:
Date Description
Business date Current business day, according to the local office calendar.
Next business date Next business day, according to the local office calendar.
Next periodicity date Calculation of next periodicity is based on the current business date.
Task Description
Daily [DALY] Clears the Total number of collections per
period counter each time the task activates.
[DALY] task must be set to the next business
day.
Weekly [WEEK] Determines the next Sunday from today
(including current date).
Sunday is not a business day, so the next
[WEEK] task invokes on Saturday. If Saturday is
not a business day, the task invokes on Friday.
Monthly [MNTH] Determines the last day of the current month.
Quarterly [QURT] Determines the last day of the quarter that is in
the months of March, June, September or
December (the closest to current date).
Half Yearly [HFYR] Determines the last day of the half year that is in
the month of June or December (the closest to
current date).
Yearly [YEAR] Determines the last day of the year that is in the
month of December.
If the 31st of December falls is on a non-
business day (for example, a holiday), then the
next [YEAR] task is set to invoke on the 30th. If
the 30th is a non-business day, the task is set to
invoke on the 29th.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 135
3.3.1.3 Business Setup
These are the details of the required setup in GPP profiles for the IBG clearing.
Note: For a detailed description of profile fields, see GPP Online Help.
3.3.1.3.1 Profiles
3.3.1.3.1.1 MOP Profile (BOOK Transactions)
This MOP Profile is used for BOOK transactions.
Field Value for IBG
General Tab
MOP BOOK
Earliest Value Date <any value>
Latest Value Date <any value>
Currency Blank
Max amount Blank
RMA check required Unchecked
Calendar Blank
Send outgoing message Unchecked
Membership Required Unchecked
Roll forward at start of day Checked
Processing Tab
Communication Preferences NONE
MOP Cycle
Closing time = 07:00
Closing time = 10:00
Closing time = 13:00
Closing time = 16:00
Closing time = 19:00
Note: MOP cycle settings not listed here follow the default MOP setting.
3.3.1.3.1.2 MOP Profile (IBG DD Transactions)
This MOP profile is used for IBG DD transactions.
Field Value for IBG
General Tab
MOP MYIBGDD
Currency MYR
Earliest Value Date
0
3.3.1.3.1.3 Identifiers Profile
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 136
This profile is used as an identifier IBG DD transactions.
Field Value for IBG
MOP MYIBGDD
Currency MYR
Identifier <NCC (Routing Number) of the local office>
Default ID for MOP office Checked
Default office for ID Checked
Settlement Account Office DHM
Account <Settlement account>
3.3.1.3.1.4 Bulking Profile
This profile is used as the bulking profile for IBG DD transactions.
Field Value for IBG
Name MYIBGDD_BULK
File Type NACHA
Min transaction per file
<not specified by MyClear>
Max transaction per bulk 9999999
Max total amount per file 9,999,999,999.99
Max total amount per bulk 9,999,999,999.99
Credit Lump Sum Checked
Outgoing Interface MYIBG_MP_BULK
3.3.1.3.1.5 Sending Time Profile
This profile is used as the sending time profile for IBG DD transactions.
Field Value for IBG
Bulking profile MYIBGDD_BULK
Time to send Checked.
Select:
06:45
09:45
12:45
15:45
18:45*
Last send time Unchecked.
*For Time to send value of 18:45, select the Last send time checkbox.
3.3.1.3.1.6 NCC Profile
This is the NCC profile used to store an IBG DD participant’s routing number.
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 137
Field Value for IBG
Department DHM
Office DHM
Clearing System ID MYIBG
Member ID <Routing number>
Party Code <Local office default party code>
3.3.1.3.1.7 Membership Profile
This profile is used as the membership profile for IBG DD participating banks.
Field Value for IBG
MOP MYIBGDD
Member Type MYIBG
Member ID
<Routing number of the participating bank 1>
Type of Membership Full
3.3.1.3.1.8 Parameters Profile
This profile is used for processing the Biller’s pain.008.
Field Value for IBG
Department DHM
Scheme MYIBGDD
Scheme Type MYIBGDD
Party Code <Party code of Biller Code from Parties profile>
Creditor ID <Biller code as registered with MyClear>
Validate DD Creditor ID Account
Validate DD creditor ID False
Validate DD creditor ID
Account False
Management Parameters
Mandate management
option Unchecked
3.3.1.3.1.9 Cut-off Times Profile
This profile is used for sending the last collection file for all IBG DD transactions.
Field Value for IBG
Cut-off name MYIBGDD_CC
Cut-off type Clearing
Time Zone MYT
Interim cut-off time 18:45
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 138
Field Value for IBG
Final cut-off time 18:45
3.3.1.3.1.10 Direct Debit Transaction Code Profile
This profile defines the Default Debit Transaction Code for all IBG DD transactions.
Field Value for IBG
Transaction code DEF_DR
Description Default DHM Debit Transaction Code
3.3.1.3.1.11 Currency Preferences Profile
This profile is used to indicate the MYR currency preference for all IBG DD transactions.
Field Value for IBG
Currency MYR
Display currency Checked
Soonest value date 0
Batch suspense account <account number>
3.3.1.3.1.12 User Codes Profile
This profile is used when GPP generates a transmittal file for preparing an IBG DD Collection file. For
each collection, GPP generates one transmittal file per IBG file.
Field Value for IBG
Type ACK
Code MYIBG_DD_MP_TRANSMITTAL_FILE
Clearing Processing Mass Payment APAC Clearing
Global PAYplus Business Guide Page 139
3.3.1.3.2 Rules
3.3.1.3.2.1 MOP Selection Rule
Rule Rule Attribute Setup Guidelines
1 Assign MYIBGDD MOP for all pain.008 files
Rule Name MYIBG_DD_MP_OUT
Attachment
DHM
Rule conditions All of the following conditions should be met:
Message type is pain_008
And
[Orgnl msg tp] = pain_008
And
[Lcl instrm hdr cd] = CTX
And
Creditor Agent NCC Proprietary = MYIBG
Action
Profile to be selected: MYIBGDD
2 Assign BOOK MOP for Inward Collections
Rule Name MYIBG_DD_MP_IN
Attachment DHM
Rule conditions All of the following conditions should be met:
[Msg tp] = NACHA_DD
Action Profile to be selected: BOOK
3.3.1.3.2.2 Incoming File Filter Rule
To validate that a file is received at the correct RFI, an FI can set the F_FILE_SOURCE condition in
the Incoming File Filter rule. This rule validates if the local bank’s routing number is the immediate
destination for files received from MyClear.
Rule Rule Attribute Setup Guidelines
1 Accepts files received for correct RFI; rejects files not designated for correct RFI.
Rule Name
MYIBG_DD_MP_IN
Attachment DHM
Rule conditions All of the following conditions should be met:
[File Source] = MYIBGDD
And
[Instd agt NCC cd] = MYIBG
And
[Instd agt ID] <><Local office routing number>
Action Rejected
3.3.1.3.2.3 Clearing Cut-off Rule
Rule Rule Attribute Setup Guidelines
1 Clearing cut off for IBGDD transactions
Rule Name MYIBG_DD_MP_CC
Attachment DHM
Clearing Processing Mass Payment APAC Clearing
Global PAYplus Business Guide Page 140
Rule Rule Attribute Setup Guidelines
Rule conditions All of the following conditions should be met:
[Cdt MOP] = MYIBGDD
Action MYIBGD_CC
3.3.1.3.2.4 Debit Transaction Code Rule
Rule Rule Attribute Setup Guidelines
1 Default code for debit transactions
Rule Name MP_DD_DR_TC
Attachment DHM
Rule conditions All of the following conditions should be met:
[Cdt MOP] = MYIBGDD
Action DEF_DR
3.3.1.3.2.5 Credit Transaction Code Rule
Rule Rule Attribute Setup Guidelines
1 Default code for credit transactions
Rule Name MP_DD_CR_TC
Attachment DHM
Rule conditions
Action
DEF_CR
3.3.1.3.2.6 Fee Bypass Rule
For incoming collections (with source MOP as MYIBGDD) or inward IBG transactions, the Fee Bypass
rule can be configured.
File Source [F_FILE_SOURCE] is a new condition with the Fee Bypass Rule. To configure the Fee
Bypass rule, an FI can set the F_FILE_SOURCE condition in the MYIBG_DD_MP_BYPASS_FEE
rule.
Note: MyClear does not charge fees to the Payer Bank.
Rule Rule Attribute Setup Guidelines
1 Bypass fees for Inward IBG transactions
Rule Name MYIBG_DD_MP_BYPASS_FEE
Attachment DHM
Rule conditions All of the following conditions should be met:
[File Source] = MYIBGDD
Action BYPASS
3.3.1.3.2.7 Advising Type Selection Rule
Rule Rule Attribute Setup Guidelines
1 Setup guidelines for selecting advising type
Rule Name MYIBG_DD_MP_DR_ADV
Attachment DHM
Clearing Processing Mass Payment APAC Clearing
Global PAYplus Business Guide Page 141
Rule Rule Attribute Setup Guidelines
Rule conditions All of the following conditions should be met:
[Msg Sts] = Completed
And
[Msg tp] = NACHA_DD
And
[Cdt MOP] = MYIBGDD
Action
ADVISING
3.3.1.3.2.8 Matching Index Rule
Rule Rule Attribute Setup Guidelines
1 Matching index for Incoming Distribution File
Rule Name MYIBG_DD_MP_FILE_DUPL
Attachment MYIBG_DD_MP_FILE_DUPL
Rule conditions All of the following conditions should be met:
[File duplicate ind] setVal [File nm]
Action Rejected
3.3.1.3.2.9 Matching Check Profile Selection Rule
The matching of Incoming DR with Outgoing DN is handled via the Matching Check profile and
Automatic Matching Algorithm mechanism. The Incoming DR links with Outgoing DN with relation
type Incoming Reject Return^Original Payment.
Rule Rule Attribute Setup Guidelines
1 File duplicate checking for Incoming Distribution File from MyClear
Rule Name MYIBG_DD_MP_FILE_DUPL
Attachment
Rule conditions All of the following conditions should be met:
F_FILE_SOURCE = MYIBGDD
Action MYIBG_DD_MP_FILE_DUPL
2 Incoming DR matching with Outgoing DN for MYIBGDD collections
Note: Attach this rule on higher priority than existing NACHA rule NACHA_IN_RTN_DD.
Rule Name MYIBG_DD_MP_IN_DR
Attachment
Rule conditions All of the following conditions should be met:
COMPARE_STRING ([Msg class], =, RDD,) Is
TRUE
And
COMPARE_STRING ([Msg tp], =,
NACHA_RTN,) Is TRUE
And
[Dbt MOP] = MYIBGDD
Action MYIBG_DD_MP_IN_DR
3.3.1.3.2.10 Mandate Validation Rule
Clearing Processing Mass Payment APAC Clearing
Global PAYplus Business Guide Page 142
Rule Rule Attribute Setup Guidelines
1 Ensures the number of Collections made against mandate for a given period does not
exceed the Max frequency per period.
Rule Name MP_DD_TOTAL_COLL_PER_PERIOD
Attachment Global office
Rule conditions All of the following conditions should be met:
BASE_CONDITION(PROCESSING_RECEIPT_VAL)
Is TRUE
And
[F_MANDATE_TOTAL_COLL_PER_PERIOD] + 1 >
[F_MAX_COLLECTION_PER_PERIOD]
And
[F_MANDATE_CDT_DBT_USAGE] = DR
And
IS_EMPTY([F_MAX_COLLECTION_PER_PERIOD])
Is Not TRUE
And
IS_EMPTY([P_MANDATE_UID]) Is Not TRUE
And
UPPER(F_MANDATE_PERIODICITY_TYPE) = PER
PERIOD
Action MP_DD_TOTAL_COLL_PER_PERIOD
The Mandate Validation rule supports these scheme validations:
# Mandate Validation Mandate Validation Rule
1 Instruction amount must be less than or equal to
the maximum amount as authorized by Payer. MP_DD_MAX_COLL_AMT
2 The number of successful debits does not exceed
the maximum frequency for each mandate as
authorized by Payer.
MP_DD_TOTAL_COLL_PER_PERIOD
3 The effective date of the mandate must be current
business date or less than current business date. MP_DD_REJECT_COL_PRIOR
4 The expiry date of mandate must not be passed
(expiry date must be greater than current business
date).
MP_DD_REJECT_COL_AFTER
5 Mandate must be active (not marked as Cancel in
GPP). MP_DD_CD_CANCELLED MANDATE
Clearing Processing Mass Payment Clearings
Global PAYplus Business Guide Page 143
3.3.1.4 STP Message Processing
3.3.1.4.1 GPP High Level Mass Payment Flow
When GPP receives an inward collection file from clearing, it parses the file into a File Summary and
Batch Summary. Individual transactions are created and processed individually. Once the collections
are debited successfully after mandate checking as per MyClear validations (as per section), GPP
generates a response DR message back to the clearing.
For the description of the end-to-end GPP mass payment flow of Incoming DN, see end-to-end GPP
mass payment flow in GPP Business Guide Mass Payments.
3.3.1.4.2 Generation of Debit Response - Outgoing DR
The Outgoing DR with R00 response is generated after the Incoming DN moves to the Complete
queue.
3.3.1.5 Outgoing DN missed DR Time Frame
This business scenario refers to the case when an outgoing DN is waiting for the response and
missed the expected time to wait for the response DR message. In this case, it is expected to reject
such outgoing DN.
• Outgoing DN is sent to MyClear.
The Outgoing DN is expected to wait for the response until DR time frame. The DR time frame
would be either default Win 2 T+1 or as per the time frame defined by the biller in Debit Retry
field.
GPP does not get the response within the DR time frame.
• GPP sends the Outgoing DN to Rejected queue using a task MYIBGDD: Outgoing collection
missed response. The task tracks the DR time frame using existing derived field
D_Max_Debit_Rtry_Date.
Clearing Processing Distributed Ledger Payment Processing
Global PAYplus Business Guide Page 144
4 Distributed Ledger Payment Processing
4.1 Clearing Processing on Distributed Payment Environment
4.1.1 Ripple
4.1.1.1 Overview
Ripple is an Internet-based technology for directly connecting banks and payment systems. Banks
can use Ripple as a common ledger to clear and settle transactions in real-time at the lowest-possible
cost. Ripple structurally alters the payment process by enabling:
• Bilateral settlement: Eliminates intermediaries, midpoint failure, delays, lifting fees
• Real-time funding: Minimizes exchange spreads, credit risk, collateral costs
The Ripple protocol enables two critical functions:
• A common ledger to connect banks and payment networks: To clear transactions, Ripple provides
continuous (24/7/365) connectivity between banks for real-time (approximately every 5 seconds)
clearing, netting and monitoring, all without a central counterparty.
• A real-time funds-exchange to settle transactions: To settle same-currency transactions, Ripple
transfers funds bilaterally; for cross-currency transactions, Ripple sources funds at the best
exchange rate from a competitive marketplace of liquidity providers.
Ripple is a neutral, decentralized protocol. It is not owned or controlled by a government or corporate
entity. Banks can use Ripple as an open standard, like other Internet protocols (for example, SMTP
for email), to facilitate connectivity and interoperability.
4.1.1.1.1 Ripple participants
Participants
Network members: Banks and financial service businesses
Network operators: Payment networks, clearinghouses
Liquidity providers: Central banks, banks, non-bank market makers
4.1.1.1.2 Message Types
GPP supports the following Message Types for Ripple within GPP:
• pacs.008/MT103 – FI to FI customer credit transfer
4.1.1.2 Business Flow
High level flow of Ripple within GPP.
Clearing Processing Distributed Ledger Payment Processing
Global PAYplus Business Guide Page 145
Clearing Processing Distributed Ledger Payment Processing
Global PAYplus Business Guide Page 146
4.1.1.3 Use Cases & Flow Processes
4.1.1.3.1 Request for ‘Get Quote’ from Ripple
Payment processing (instructing bank) – get quote
Feeder / Manual GPP Other systems Ripple
Pain.001 Process
payment
Pefrom first compliance
Cdt MOP = Ripple
MOP exit point with get quote.
Generate ‘Get
Quote’ Request
‘Get Quote’
request
Process quote
‘Get quote’
response
Success?
Match response
to request
Status = Wait
Rate
Copy details from response to payment:
q
Beneficiary details
q
Beneficiary side fees
q
Quote expiration date and time
q
Etc.
true
false
Status = Repair /
Quote Exception
Retry
Quote
Status = FX Rate
Verify Queue
Verify
1
When a payment is received, GPP performs validations and selections, for example, validation,
debit/credit party identification, MOP selection.
When Ripple is selected, GPP uses an exit point to go for ‘Get Quote’ request form Ripple. When
waiting for quote, the payment is routed to Wait Rate queue.
Once the rate is received and the rate response is matched to the request, the payment is routed to
the FX Rate Verify queue for manual rate verification.
Clearing Processing Distributed Ledger Payment Processing
Global PAYplus Business Guide Page 147
4.1.1.3.2 Receipt of Get Quote Response from Ripple
Payment processing (Instructing bank) – Accept quote
Feeder / Manual GPP Other systems Ripple
1
Validate Quote
expiration
Quote
expired
yes
Status = Repair /
Quote Exception
Retry
Quote
no
Generate
‘Accept quote’
request
‘Accept quote’
request
Status = Wait
Confirmation
Process ‘Accept
quote’
‘Accept quote’
response
Match response
to request
Success?
false
Status = Repair /
Quote Exception
Retry
Quote
true
Status =
accepted?
2
Once the user verifies the rate, GPP generates ‘Accept Quote’ request. The payment is routed to the
Wait Confirmation queue. An ‘Accept Quote’ response is matched to the request and if status is
accepted, the payment continues to the next processing step.
Clearing Processing Distributed Ledger Payment Processing
Global PAYplus Business Guide Page 148
4.1.1.3.3 Execute Payment to Ripple (Instructing Agent)
Payment processing (Instructing bank) – Execute payment
Feeder / Manual GPP Other systems Ripple
2
Get ‘locked’
payments
‘Locked’
payments query
‘Locked’
Payments
For each payment
Load payment
(by ID)
Posting
yes
Posting request
Posting OK?
Status = posting
exception
yes
no
Submit
[sending]
payment
Sending
payment
Execute
payment
Sending
payment
response
Status = wait
confirmation
State
Match response
to request
Succeeded
failed In progress
Status = Wait
Confirmation
Status =
complete
Status = NAK \
Rejected
q Dr debtor
q Cr clearing suspense
q Cr fee PNL
Compliance
check
Success?
Compliance
Exception
Queue
Compliance
check request
GPP checks with Ripple Connect (RC) for a payment with status Locked payments to match to
original request payment. GPP matches the response to the request. Performs compliance checking
and posting.
• If a positive response is received, GPP sends the payment to Complete queue.
Clearing Processing Distributed Ledger Payment Processing
Global PAYplus Business Guide Page 149
• If NAK is received, GPP sends the payment to Rejected queue.
4.1.1.3.4 Get Payment Accepted (At the Instructed Agent)
Payment processing (Instructed bank) – Get Accepted Payment
Feeder / Manual GPP Other systems Ripple
Get ‘accepted’
payments
‘Accepted’
payments query
‘Accepted’
Payments
For each payment
Create payment
no
Compliance
Compliance
OK?
Status = Compliance
exception
Compliance
check request
Validations
& processing
Status = Rejected? Valid?
yes
no
Generate ‘Lock
quote’ request
yes
‘Lock quote’
response
‘Lock quote’
request
Process ‘Lockt
quote’
Status = Wait Lock?
false
Match response
to request
Success?
Status = Repair /
Quote Exception
Status = locked? \
Release?
true
3
q Duplicate check
q Dr MOP – Ripple
q Source STP validation
q Dr side processing
q Cr side processing
q Cr MOP book
• Receiving bank gets the payments that were accepted.
Clearing Processing Distributed Ledger Payment Processing
Global PAYplus Business Guide Page 150
• Debit MOP is identified as Ripple.
4.1.1.3.5 Execute Payment (at the Instructed Agent)
Payment processing (Instructed bank) – Execute payment
Feeder / Manual GPP Other systems Ripple
3
For each payment
‘In progress’
Payments
‘In progress’
payments query
Load payment
(by ID)
Get ‘In
progress’
payments
yes
no
Posting request
Posting OK?
Status = posting
exception
Posting
q Dr clearing suspense
q Cr beneficiary
q Cr fee PNL
POST
Reciving
payment
Submit
[receiving]
payment
Status = Wait
confirmation?
Sending
payment
response
Match response
to request
Execute
payment
State
Succeeded
Status =
complete
failed
Status = ?
The payment is now in Completion Processing. GPP:
• Gets payments that were paid
• Identifies funds that have been transferred
• Continues workflow (or selects posting workflow)
• Executes posting
Clearing Processing Distributed Ledger Payment Processing
Global PAYplus Business Guide Page 151
• Completes processing and sends SMS to beneficiary
• Changes status to Complete
4.1.1.4 Business Setup
Setup Additional Information
System Parameters N/A
Profiles MOP Selection Profiles
Rules
N/A
Permissions
N/A
Tasks
N/A
queues N/A
System Configuration Interface profile
4.1.1.4.1 Profiles
4.1.1.4.1.1 MOP Selection
On the initiating party a MOP Ripple should be defined
Field Value for Ripple Comment
Name
Ripple
Calendar
Relevant calendar or
no value
On the receiving party MOP Lock should be defined as the payment is not completed until the
initiating party accepts the payment. Then MOP Book is selected and accounting is performed.
4.1.1.4.2 System Configuration
Interface Profile with connectivity of Get Quote needs to be defined.
Clearing Processing Appendix A: Glossary
Global PAYplus Business Guide Page 152
Appendix A: Glossary
This table describes the terms used in this document.
Term Description
Account Identifier The Identifier used within the Business Reference Data to resolve to a
Participant that acts as the Account Servicer.
Abort Termination of the payment instruction processing by the Basic
Infrastructure as a result of an error or exception preventing the
completion of the transaction.
Abort Notification A system message that alerts the sender of an acknowledged, live input
message that the system has aborted the delivery of the message. An
error code indicates the reason for the delivery abort
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.
ACK A positive technical acknowledgement.
ACTC File Acceptance. A file reason code indicating an accepted technical
validation, which means successful authentication, both syntactically and
semantically.
ADI Authorized Deposit-taking Institution as set out by APRA
Addressing Service Delivers the ability to identify an account at a Participant as the
destination for a message using the Alias Identifier (such as a mobile
phone number or email address) of the Payee rather than the account
number.
Alias An Alias is a unique identifier which can be used through the Addressing
Service to identify a serviceable account through reference to the Alias
Record. The Alias includes both the Alias Type and the Alias Identifier (for
example ‘email’ and ‘wsmith@gmail.com’)
AN Abort Notification from FSS to Payee Bank and Payer Bank PAG to
Payee Payer Bank’s BOs
AOS Additional Optional Services
APCA Australian Payments Clearing Association Limited
APRA Australia Prudential Regulation Authority
Available The positive state of Availability where a computer system is available for
use. In the context of NPP, a measure of how long a system (participant
or BI) is available and able to process or respond to NPP messages.
BAH Business Application Header
Basic Messaging Basic Messages are messages that do not form part of the orchestrated
transaction flow (pacs.008/ 002/009).
BAU Business as Usual
BI Basic Infrastructure network and Addressing Service operated by SWIFT,
with link settlement via the FSS.
BIC Business Identifier Code. BIC is an international standard for identification
of institutions within the financial services industry. BICs are used in
automated processing to unambiguously identify a financial institution or a
non-financial institution. The ISO 9362 standard specifies the elements
and the structure of a BIC. A BIC consists of either eight (BIC8) or eleven
(BIC11) contiguous characters.
BO Back Office – A participant’s Back Office systems
Clearing Processing Appendix A: Glossary
Global PAYplus Business Guide Page 153
Term Description
BSA Batch Suspense Account. A posting account used to accumulate
transactions for consolidated posting.
Business Day A working day other than a Saturday, Sunday or legal public holiday.
Business Retry Business Retry is the sending of the same business transaction in a new
message with a new Transaction ID.
CBT CHAPS Central Bank Interface
CHAPS Clearing House Automated Payment System
CHESS Clearing House Electronic Subregister System
CID Creditor ID. Unique creditor identification code supplied by a creditor
bank. GPP uses the CID and the UMR to identify a mandate.
CN Clearing Notification – pacs.002 from Payee Bank to Payer Bank and vice
versa
CR Clearing Request – pacs.008 from Payer Bank to Payee Bank
CSM Clearing and Settlement Mechanism
CTO Credit Transfer Outgoing
CUG Closed User Group
DC Direct Clearing
DD Direct Debit
DDA Direct Debtor Authorization
DDO Direct Debit Outgoing
Debtor The party that owes an amount of money to the creditor, and/or a debit
account owner.
DFI Depository Financial Institution. A bank or other financial institution.
DS Direct Settlement
Direct Deposit A credit transfer in a NACHA-based system.
Direct Payment A direct debit in a NACHA-based system.
DUPEX Duplication exception.
ENRP
A file received from a clearing that loads a mandate in GPP.
ESA Exchange Settlement Account; An account held at the RBA by financial
institutions to settle financial obligations arising from the clearing of
payments.
FI Financial Institution
Final status One of the following statuses beyond which no manual or system
processing will be done - Complete, Reject, Cancelled, etc.
FSS Fast Settlement Service - RITS Fast Settlement Service operated by the
Reserve Bank of Australia
FSS Outage An FSS Outage is defined as the period during which the FSS (PAG and
BO combination) is consistently unable to respond to Settlement
Requests being received from all Participant PAGs.
Full Legal Account
Name Full Legal Account Name (FLAN) means the full account name as
allocated by the Account Servicer based on Know Your Customer
procedures. This may be different to other names used for the account
and sometimes different to the names of the account owner(s) – such as
when a trading name is appended. It is a name determined by the Bank
and is not controlled by the customer. Guidance – The FLAN is the name
Clearing Processing Appendix A: Glossary
Global PAYplus Business Guide Page 154
Term Description
of the individual or organization that owns the account, not who controls
the account. It deals with ownership rather than the authority to use the
account. For example, this could be from a Participants core banking
system or statements system.
Gateway
Point of entry or exit into the Basic messaging infrastructure.
GIRO A giro (or giro transfer) is a payment transfer from one bank account to
another bank account and instigated by the PAYER, not the payee.
GPP
Global PAYplus
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.
HLD SWIFT High Level Design for the NPP
HVCS High Value Clearing System
IC Indirect Clearing
Interface Services A secure means for Participants to connect to the BI. Interface services
include sending and receiving messages, receiving enquiries, and
providing access to the helpdesk and settlement.
Intrabank Transfers A transaction scenario that occurs when both parties to an Austraclear
transaction are bank customers, potentially causing the Austraclear Trade
to result in both an MT198-036 and MT198-037 being received for the
same Austraclear trade transaction.
IP Immediate Payment
IS Indirect Settlement
MAS Monetary Authority of Singapore
MEPS MAS Electronic Payment System
Message Processing The processing of messages submitted to the Switch by Participants,
FSS, and Overlay Services. This includes the Switch processing of
payment messages (single Credit Transfers), non-value messages
(business and technical), settlement messages (settlement request and
notification), error and exception notification messages, and Overlay
Service messages.
MOP Method of Payment. The means via which a payment is executed, such
as BOOK or SWIFT.
MP
Mass Payments
MQ IBM WebSphere MQ (Message Queue)
NAB National Australia Bank Limited
N/A Not applicable
NCC National Clearing Code
Net Accounting Accounting method that performs postings for processed transactions
only. Posting is not performed for rejected or canceled transactions.
NPP New Payments Platform at an FI that:
• Facilitates on a 24x7 basis near real-time settlement of payment
transactions in Australian dollars without having to specify full
destination account details and provide more complete remittance
information, such settlement to be effected through the RBA
Clearing Processing Appendix A: Glossary
Global PAYplus Business Guide Page 155
Term Description
• Is accessible to all ADIs (and other approved entities) on an equitable
basis
• Is efficient, flexible and scalable and has high levels of reliability and
security
• Supports ongoing innovation in payment services including through
enablement of multiple overlay services tailored to payment needs.
NPPA NPP Australia Limited, a mutual organization, which owns and governs
the core business architecture (Basic Infrastructure). The NPPA's
membership consists of Participants and other approved entities.
ON-US Payment A payment where the drawing and paying accounts are at the same FI.
pacs Payments Clearing and Settlement messages sent only by ADI
Participants
PAG SWIFT Payment Access Gateway (Clearing Gateway), a component of
the Distributed Switch embedding the business logic for processing the
payment clearing and settlement flows.
PAIN Payments Initiation messages originating from Participants’, Connected
Institutions and from connected Overlay Services
PART Partial File Rejection. A file reason code indicating that one or more
payments are rejected.
Participant
A shareholder of NPPA
Payee bank The receiver of the Credit transfers through FSS
Payer bank The sender of the Credit transfers through FSS
PDA NPP Program Delivery Authority
PDE Possible Duplication Emission flag
PDO Payment Data Object. Data object that holds all payment data, including:
XML message date (original and enriched)
Relational data
Reference data
Rates, fees, and errors
PDS Payment Delivery System
RBA Reserve Bank of Australia
R Message GPP supports recall, return, and reject messages for both the originating
bank and the receiving bank.
RITS Reserve Bank Information & Transfer System used for interbank
settlement
RJCT File Rejection. A file reason code indicating a rejected settlement, rejected
payment initiation, or rejected individual transaction.
RPO Recovery Point Objective
RTO Recovery Time Objective
RTGS Real-Time Gross Settlement. A settlement system that transfers funds in
real-time, processes each transaction upon receipt, and settles each
transaction individually.
SEPA Single Euro Payments Area. A European financial infrastructure that
creates a zone in which Euro payments (or any other agreed upon
currency) are considered domestic.
SLA Service Level Agreement, as it may apply to SWIFT or Participants
Clearing Processing Appendix A: Glossary
Global PAYplus Business Guide Page 156
Term Description
SN Settlement Notification – pacs.002 from FSS to Payee Bank and Payer
Bank
SR Settlement Request generated automatically from the Payer PAG after
receipt of a successful CN
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.
SWIFT Interface The bundle of software constituting the Switch, including the PAG and
DMC.
TPS Transactions Per Second. The number of transactions GPP is able to
process per second.
Transfer To sell, transfer, assign or otherwise dispose of, create or deal with any
legal or equitable interest in a Share.
UMR Unique Mandate Reference. Unique mandate identification code supplied
by a creditor. GPP uses the UMR and the CID to identify a mandate.
Unavailable The negative state of Availability where a computer system is not
available for use. In the context of NPP clearing, a measure of how long a
system (participant or BI) is not available and thus not able to process or
respond to NPP messages.
Under Stress This state occurs when BO systems are consistently unable to meet the
Clearing Response SLA and will not be able to improve in short term
without intervention. A Participant BO environment is deemed to be under
stress for one or more business services and they require action by other
NPP counterparties to restrict message delivery to their PAGs and BO
environment

Navigation menu