Business Guide GPP Clearing Processing
User Manual: Pdf
Open the PDF directly: View PDF 
.
Page Count: 156
| Download | |
| Open PDF In Browser | View PDF |
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
Version Control
Version
Date
1.0
Summary of Changes
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
Global PAYplus Business Guide
Page 3
Clearing Processing
Table of Contents
Table of Contents
1
INTRODUCTION ................................................................................................................ 5
1.1
2
Target Audience........................................................................................................... 5
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
Global PAYplus Business Guide
Page 4
Clearing Processing
1
Introduction
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.
Global PAYplus Business Guide
Page 5
Clearing Processing
2
Generic Clearing Processing
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
103
103
Description
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.
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.
Global PAYplus Business Guide
Page 6
Clearing Processing
Message
Type
Sub
Type
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 7
Clearing Processing
2.2.1
Generic Clearing Processing
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
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
Global PAYplus Business Guide
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
Page 8
Clearing Processing
Generic Clearing Processing
MT
Outward/
Inward
Processing
Flow
Clearing
Response
GPP Queue
103, 103+,
202,
202COV
Inward
from
clearing
Inward STP
payment from
clearing
N/A
Complete
Inward
from
clearing
Inward NonSTP 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
Comments
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
Global PAYplus Business Guide
Page 9
Clearing Processing
Generic Clearing Processing
2.3 Single Payment EU Clearing
2.3.1
2.3.1.1
TARGET2
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
2.3.1.2.1
Inward/Outward Processing
Inward Processing from TARGET2
1. A payment received from TARGET2 has these values:
Global PAYplus Business Guide
Page 10
Clearing Processing
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 11
Clearing Processing
2.3.1.5.1
Generic Clearing Processing
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
Name
TARGET2
Calendar
Relevant calendar or no value
MOP Business Date
Current business day 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
Comment
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.
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
Global PAYplus Business Guide
Page 12
Clearing Processing
Generic Clearing Processing
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
Cut-off name
TARGET2_cust
TARGET2_B2B
Cut-off type
Clearing
Clearing
Time zone
GMT
GMT
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
Comment
Time zone for aligning cut-off
times
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
MOP
TARGET2
Type of
Membership
Full member for TARGET2
participants (or associates)
Global PAYplus Business Guide
Comment
This membership record needs to be setup
only for the direct participant
Page 13
Clearing Processing
2.3.1.5.5
Generic Clearing Processing
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
MOP
TARGET2
Identifier
Bank BIC
Settlement
account
Office, Account number, Currency
2.3.1.5.6
Comment
In a multi office setup the identifier is setup
only for the direct participant office
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
TARG
ET21
N/A
TARGET2
MOP
selection rule
Local
office
Global PAYplus Business Guide
AND/
OR
Field
Operator
Value/
Field/
Function
Action
[Sttl
m
Ccy]
=
EUR
AND
[Msg
tp]
IN
SWIFT_1
03,
SWIFT_2
02
SET
MOP
Profile
TARGET
2
AND
[Cdtr
Agt
ctry]
=
DE, FR,
IT, ….
Page 14
Clearing Processing
2.3.1.6.2
Generic Clearing Processing
Clearing Cut Off
Rule
Name
Rule
Sub
Type
Description
Attached
to
TARG
ET2_
Cust
N/A
TARGET2
cut off
selection rule
for MT103
Local
office
TARGET2
cut off
selection rule
for MT202
Local
office
TARG
ET2_
B2B
2.3.1.6.3
N/A
Field
Operator
Value/
Field/
Function
Action
[Cdt
MOP
]
=
TARGET2
[Msg
tp]
=
SWIFT_1
03
SET
TARGET
2_cust
cut off
(17:00)
[Cdt
MOP
]
=
TARGET2
AND
[Msg
tp]
=
SWIFT_2
02
AND/
OR
Field
Operator
Value/
Field/
Function
Action
[Cdt
MOP
]
=
TARGET2
NN
AND
SET
TARGET
2_B2B
cut off
(18:00)
Liquidity Priority Selection Rules
Rule
Name
Rule
Sub
Type
Description
Attached
to
TGT_
PRIO
RITY_
1
N/A
Set NYNN
priority for all
TGT
payments
Local
office
2.3.1.7
AND/
OR
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.
Global PAYplus Business Guide
Page 15
Clearing Processing
2.3.2
2.3.2.1
Generic Clearing Processing
EURO1
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.
Global PAYplus Business Guide
Page 16
Clearing Processing
2.3.2.2.1
Generic Clearing Processing
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
Global PAYplus Business Guide
Page 17
Clearing Processing
Generic Clearing Processing
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
Name
EURO1
Calendar
Relevant calendar or no
value
MOP Business
Date
Current business day 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
Comment
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.
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
Global PAYplus Business Guide
Page 18
Clearing Processing
Generic Clearing Processing
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
Cut-off name
EURO1_cust
EURO1_B2B
Cut-off type
Clearing
Clearing
Time zone
GMT
GMT
Description
EURO1 Clearing Cutoff 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
Comment
Time zone for aligning cut-off
times
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
MOP
EURO1
Type of
Membership
Full member for EURO1
participants (or associates)
2.3.2.4.1.5
Comment
Identifiers Profile
The EURO1 Identifiers profile is used to set up and view the party identifiers and settlement account
information for the MOP.
Global PAYplus Business Guide
Page 19
Clearing Processing
Generic Clearing Processing
These are the specific attributes that need to be defined in the Identifiers profile for EURO1 Clearing.
Field
Value for EURO1
MOP
EURO1
Identifier
Bank BIC
Settlement
account
Office, Account number,
Currency
2.3.2.4.1.6
Comment
In a multi-office setup, the identifier is defined only
for the direct participant office
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
EURO
1_1
N/A
EURO1 MOP
selection rule
Local
office
2.3.2.4.2.2
AND/
OR
Field
Operator
Value/
Field/
Function
Action
[Sttl
m
Ccy]
=
EUR
AND
[Msg
tp]
IN
SWIFT_1
03,
SWIFT_2
02
SET
MOP
Profile
EURO1
AND
[Cdtr
Agt
ctry]
=
DE, FR,
IT, ….
Clearing Cut Off
Global PAYplus Business Guide
Page 20
Clearing Processing
Generic Clearing Processing
Rule
Name
Rule
Sub
Type
Description
Attached
to
EURO
1
N/A
EURO1 cut
off selection
rule
Local
office
2.3.2.4.2.3
Rule
Sub
Type
Description
Attached
to
TGT_
PRIO
RITY_
1
N/A
Set NYNN
priority for all
TGT
payments
Local
office
2.3.3.1
Field
Operator
Value/
Field/
Function
Action
[Cdt
MOP
]
=
EURO1
SET
EURO1
cut off
(16:00)
Field
Operator
Value/
Field/
Function
Action
[Cdt
MOP
]
=
EURO1
NN
Liquidity Priority Selection Rules
Rule
Name
2.3.3
AND/
OR
AND/
OR
UK CHAPS
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.
Global PAYplus Business Guide
Page 21
Clearing Processing
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 22
Clearing Processing
•
Generic Clearing Processing
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:
Global PAYplus Business Guide
Page 23
Clearing Processing
Generic Clearing Processing
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
Rules
MOP selection, Clearing Cut-off, Liquidity
Priority Selection Rules
Permissions
N/A
Tasks
N/A
Queues
N/A
2.3.3.4.1
Profiles
Rules
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
Name
CHAPS
Calendar
Relevant calendar or
no value
MOP Business Date
Current business day
for the MOP
Currency
GBP
Settlement
accounting
CHAPS settlement
account
Membership
Required
Must be selected
Membership type
MOP
Global PAYplus Business Guide
Comment
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.
Page 24
Clearing Processing
Generic Clearing Processing
Field
Value for CHAPS
Send outgoing
message
Must be selected
Settlement account
exists
Must be selected
Comment
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.
Global PAYplus Business Guide
Page 25
Clearing Processing
Generic Clearing Processing
Field
CHAPS for Customer
Payment
CHAPS for Bank to
Bank Payments
Cut-off name
CHAPS_cust
CHAPS_B2B
Cut-off type
Clearing
Clearing
Time zone
GMT
GMT
Description
CHAPS Clearing Cutoff for customer
payments
CHAPS Clearing Cutoff for bank to bank
payments
Cut-off time
16:00
16:20
2.3.3.4.1.4
Comment
Time zone for aligning cut-off
times
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
MOP
CHAPS
Type of
Membership
Full member for CHAPS participants (or
associates)
2.3.3.4.1.5
Comment
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
MOP
CHAPS
Identifier
Bank BIC
Settlement
account
Office, Account number, Currency
2.3.3.4.1.6
Comment
In a multi office setup the identifier is
defined only for the direct participant
office
User Codes
User codes for liquidity priority codes should be defined for CHAPS payments tag 113 (for example, 50,
35).
Field
Value for CHAPS
Type
LIQ_PRTY
Code
Example: UP
Description
Example: CHAPS – Banking priority
urgent
Global PAYplus Business Guide
Comment
Page 26
Clearing Processing
2.3.3.4.2
Generic Clearing Processing
Rules
These are examples of user defined rules.
2.3.3.4.2.1
MOP Selection
Rule
Name
Rule
Sub
Type
Description
Attached
to
CHAP
S _1
N/A
CHAPS MOP
selection rule
Local
office
AND/
OR
Field
Operator
Value/
Field/
Function
Action
[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
CHAP
S_Cu
st
N/A
CHAPS cut
off selection
rule for
MT103
Local
office
CHAP
S_B2
B
N/A
CHAPS cut
off selection
rule for
MT202
Local
office
2.3.3.4.2.2
AN
D/O
R
AN
D
AN
D
Field
Operator
Value/
Field/
Function
Action
[Cdt
MOP]
=
CHAPS
[Msg tp]
=
SWIFT_103
SET
CHAP
S cut
off
(16:00)
[Cdt
MOP]
=
CHAPS
[Msg tp]
=
SWIFT_202
Field
Operator
Value/
Field/
Function
Action
[Cdt
MOP]
=
CHAPS
RR35
SET
CHAP
S cut
off
B2B
cut off
(16:20)
Liquidity Priority Selection Rules
Rule
Name
Rule
Sub
Type
Description
Attache
d to
CHAP
S_PRI
ORIT
Y_35
N/A
Set RR35
priority for all
CHAPS
payments
above 10M
Local
office
Global PAYplus Business Guide
AN
D/O
R
Page 27
Clearing Processing
Rule
Name
Rule
Sub
Type
Description
Global PAYplus Business Guide
Generic Clearing Processing
Attache
d to
AN
D/O
R
Field
Operator
Value/
Field/
Function
AN
D
[Orgnl
sttlm
amt]
>=
10,000,000
Action
Page 28
Clearing Processing
Generic Clearing Processing
2.4 Single Payment APAC Clearing
2.4.1
2.4.1.1
Australia - RITS PDS
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
Global PAYplus Business Guide
Page 29
Clearing Processing
2.4.1.2
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 30
Clearing Processing
Generic Clearing Processing
•
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.
Global PAYplus Business Guide
Page 31
Clearing Processing
2.4.1.3
Generic Clearing Processing
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
Name
PDS
Description
AU PDS Clearing MOP
(RITS)
Calendar
PDS_AU
MOP Business Date
Current business day
for the MOP
Value date extension
7
Currency
AUD
Settlement accounting
PDS settlement
account
Global PAYplus Business Guide
Comment
If no calendar is assigned, the default calendar for
the office is used.
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.
Page 32
Clearing Processing
Generic Clearing Processing
Field
Value for AU RITS
Membership Required
Must be selected
Membership type
MOP
Send outgoing
message
Must be selected
Settlement account
exists
Must be selected
Comment
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
Department
TBD
Office
AU1
Cut-off name
PDS_WINT
Cut-off type
Clearing
Time zone
AEST
Description
PDS AU Winter
Clearing Cut-off
Interim cut-off time
16:30
Final cut-off time
18:05
Comment
Australia Eastern Standard Time (GMT+10)
From this time until the final cut-off, only MT202 is
accepted
2.4.1.4.1.3.1 PDS Summer Cut-off
Label in Profile
Value for AU RITS
Department
TBD
Office
AU1
Cut-off name
PDS_SUMM
Global PAYplus Business Guide
Comment
Page 33
Clearing Processing
Generic Clearing Processing
Label in Profile
Value for AU RITS
Cut-off type
Clearing
Time zone
AEST
Description
PDS AU Summer
Clearing Cut-off
Interim cut-off time
16:30
Final cut-off time
20:05
2.4.1.4.1.4
Comment
Australia Eastern Standard Time (GMT+10)
From this time until the final cut-off, only MT202 is
accepted
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
MOP
PDS
Type of Membership
Full member for AU
RITS participants
(or associates)
2.4.1.4.1.5
Comment
PDS BICs are set as full members of RITS.
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
MOP
PDS
Identifier
Settlement Account:
Office
AU1
2.4.1.4.1.6
Comment
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.
Global PAYplus Business Guide
Page 34
Clearing Processing
Generic Clearing Processing
Label in Profile
Value for AU RITS
Comment
Clearing system ID
AUBSB
Australia – AUBSB
Member ID
2.4.1.4.1.7
BSB Code
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
PDS_
MOP
N/A
PDS MOP
Selection
Rule
AU1
2.4.1.4.2.2
AND/
OR
Field
Oper
ator
Value/
Field/
Function
Action
[Sttlm
Ccy]
=
AUD
AND
[Msg
tp]
IN
SWIFT_1
03,
'SWIFT_2
02'
SET
MOP
Profile
AU1^P
DS
AND
[Cdtr
ctry]
=
AU
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
WINT
ER_S
CHED
N/A
Base
condition for
winter cut-off
period
AU1
AND/
OR
and
and
Global PAYplus Business Guide
Field
Oper
ator
Value/
Field/
Function
(
DATE_EXTRAC
T(YEAR,[P_CRE
ATE_DT])
=
2014
(
(
DATE_EXTRAC
T(DAY,[P_CREA
TE_DT]
>=
5
)
DATE_EXTRAC
T(MONTH,[P_C
REATE_DT])
=
10
)
Page 35
Clearing Processing
Rule
Name
Rule
Sub
Type
Description
Generic Clearing Processing
Attached
to
AND/
OR
Field
Oper
ator
Value/
Field/
Function
DATE_EXTRAC
T(MONTH,[P_C
REATE_DT])
>
10
DATE_EXTRAC
T(YEAR,[P_CRE
ATE_DT]
=
2015
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
[Cdt MOP]
=
PDS
BASE_CONDITI
ON(WINTER_SC
HED)
=
TRUE
[Cdt MOP]
=
PDS
AND
BASE_CONDITI
ON(WINTER_SC
HED)
=
FALSE
AND/
OR
Field
Oper
ator
Value/Fiel
d/Functio
n
[Cdt
MOP]
=
PDS
AND
[Msg
tp]
=
SWIFT_2
02
AND/
OR
Field
Oper
ator
Value/Fiel
d/Functio
n
Action
[Msg
tp]
in
SWIFT_1
03,
SWIFT_2
02
SET
party
type
or
(
or
and
WINT
_CUT
OFF
N/A
SUM
M_CU
TOFF
N/A
2.4.1.4.2.3
Rule
Name
PDS
Clearing cutoff - winter
AU1
PDS
Clearing cutoff - summer
AU1
AND
(
)
)
)
)
Missed Clearing Cut-off
Rule
Sub
Type
PDS_
202_C
UTOF
F
2.4.1.4.2.4
Description
Attached
to
Allow
treasury
payments
during
interim cutoff
AU1
Action
Party Details Enrichment
Rule
Name
Rule
Sub
Type
Description
Attached
to
ENRI
CHDE
FAUL
TNCC
Party
detail
s
enric
Enrich
default NCC
if BIC exist
AU1, AU2
Global PAYplus Business Guide
Page 36
Clearing Processing
Rule
Name
ENRI
CHTR
EASU
RYNC
C
Rule
Sub
Type
Description
hme
nt
and NCC
doesn't exist
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
Generic Clearing Processing
Attached
to
AND/
OR
Field
Oper
ator
Value/Fiel
d/Functio
n
Action
AND
[First
in cdt
chain
BIC]
Is not
Empty
AND
[First
in cdt
chain
NCC]
is
Empty
FIRSTI
NCR
...
usage
DEFA
ULT_N
CC
AND
[Cdt
MOP]
=
PDS
[Msg
tp]
=
SWIFT_2
02
AND
[First
in cdt
chain
BIC]
Is not
Empty
AND
[First
in cdt
chain
NCC]
Is
Empty
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
AU1, AU2
AND
Global PAYplus Business Guide
(
SET
party
type
FIRSTI
NCR
...
usage
TREAS
URY_
NCC
)
Page 37
Clearing Processing
2.4.2
2.4.2.1
Generic Clearing Processing
Australia - RITS Austraclear
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
Global PAYplus Business Guide
Page 38
Clearing Processing
Generic Clearing Processing
•
SMT037 – Inward credit transfer single payment
•
SMT038 – Inward direct debit single payment
2.4.2.1.3
RITS Payment Flow
10. Unsettled Tx EOD Advice: RITS sends MT198-038 to
notify the paying bank that there are transactions
which remain unsettled at the end of the Settlement
session.
8. Post Settlement Advice: RITS sends MT198-036 to
say payment made
Note, could get SMT036 without SMT027/028. Would
then process accounting off SMT036
7. RITS responds with MT198-008/032 confirm
payment status change accepted
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.
4. Pre Settlement Advice: RITS sends MT198 -027/028
to debit bank for approval. RITS holds payment with
Credit status Deferred (‘D’) until approved (‘A’).
10
8
7
6
4
GPP
(Buyer Bank)
9
5
DD HV flow
9
SWIFT
8. Post Settlement Advice: RITS sends MT198-037 to
confirm payment made
8
10
8
7
6
4
RBA RITS
RTGS
SWIFT
11
Termination
flow
Cancellation
flow
3. Details sent to
RITS to arrange
payment
10. RITS advises
Austraclear that
payment done so
securities can be
moved
13
3
GPP
(Seller Bank)
12
CT HV flow
12. Bank
credits the
seller
5. Bank performs Credit Check and posting for debit
customer
Austraclear
9. In case of MT198-036 that was matched to SMT027/
028, SMT036 will perform termination flow and
process to complete.
In case of MT198-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
8
1
Party 1 Buyer (Debit)
2
Party 2 Seller (Credit)
1. Two Austraclear registered corporates do money
market deal WPAC corporate buys securities, therefore
pays
2. Deal approved by both parties
2.4.2.2
2.4.2.2.1
2.4.2.2.1.1
Inward Processing
Purchase of Securities (Buyer Bank)
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.
Global PAYplus Business Guide
Page 39
Clearing Processing
Generic Clearing Processing
Purchase of Securities (Buyer Bank) - Pre Settlement MT198-027/028
Reserve Bank
Austraclear
GPP
Pre settlement advice
MT198 – 027/028
SMT027
in
Complete
Back Office Systems
Payment
Initiation
Matched to an
existing SMT036?
Yes
No
Source
Side
processing
MT210RV
R in
Complete
Account Validation
Matched with an
existing
MT210RVR?
Yes
Destinatio
n Side
Processing
Dr/Cr
Account Validation
CDB
BI Request
Core Banking
MOP
Selection
Payment
Execution
(Fees, FX,
Stop Flags)
Balance Check
Wait BI
BI Response
Accounting
Posting/Advice Request
Core Banking
Wait
Posting
Posting Response
Interbank or
Intrabank?
Intrabank
Austraclear
Change Status Request
MT198 – 007/031
Liquidity
Update
Generate
transaction
Wait
Post avd
Change Status Response
MT198 – 008/032
Post Settlement advice – Debit
MT198 - 036
Interbank
Matched?
No
Complet
e
(MT198027/028)
Yes
Post Settlement
advice MT198036 flow
Phase
Post Settlement
advice MT198036 flow
Yes
Global PAYplus Business Guide
Page 40
Clearing Processing
Generic Clearing Processing
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 (MT198027/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 preadvice 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.
Global PAYplus Business Guide
Page 41
Clearing Processing
2.4.2.2.1.2
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 42
Clearing Processing
Generic Clearing Processing
Purchase of Securities (Buyer Bank) – Post Settlement MT198-036
Reserve Bank
Austraclear
GPP
Back Office Systems
Payment
Initiation
Post settlement advice
MT198 – 036
Matched to an
existing SMT027/
028?
Yes
Party
Processing
Dr/Cr
No
Party
Processing
Dr/Cr
Account Validation
CDB
Account Validation
MOP
Selection
MOP
Selection
Accounting (2nd
leg accounting)
Payment
Execution
(Fees, FX,
Stop Flags)
Core Banking
Posting Request
Posting Response
Wait
Posting
BI Request
Balance Check
Interbank
Core Banking
Interbank or
Intrabank?
Wait BI
Liquidity
Update
BI Response
Intrabank
MT198 036 in
Complet
e
Accounting (One
step accounting)
Posting Request
Core Banking
Wait
Posting
Posting Response?
Interbank or
Intrabank?
Interbank
Liquidity
Update
Intrabank
Phase
Complet
e
(MT198036)
Global PAYplus Business Guide
Page 43
Clearing Processing
Generic Clearing Processing
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 presettlement 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
2.4.2.2.2.1
Sale of Securities (Seller Bank)
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.
Global PAYplus Business Guide
Page 44
Clearing Processing
Generic Clearing Processing
Sell of Securities (Seller Bank) - Post Settlement MT198 - 037
Reserve Bank
Austraclear
GPP
Payment
Initiation
Post settlement advice - Credit
MT198 – 037
MT210R
VR in
Service
Complete
Back Office Systems
Yes
Matched with an
existing
MT210RVR?
No
Party
Processing
Dr/Cr
Account Validation
CDB
Compliance Request
Core Banking
MOP
Selection
Payment
Execution
(Fees, FX,
Stop Flags)
Compliance
Compliance Response
Accounting
Posting Request
Core Banking
Wait
Posting
Posting
Response
Interbank or
Intrabank?
Interbank
Liquidity
Update
Intrabank
Phase
Complet
e
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.
Global PAYplus Business Guide
Page 45
Clearing Processing
o
Generic Clearing Processing
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
2.4.2.2.3.1
Exception Handling
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.
Global PAYplus Business Guide
Page 46
Clearing Processing
Generic Clearing Processing
Sell of Securities
Unsettled
Advice(Seller
MT198Bank)
- 038
Reserve Bank
Austraclear
GPP
Matched to an
existing SMT027/
028?
Unsettled advice
MT198 – 038
No
Yes
Service
Release
Queue
Back Office Systems
Yes
Service
Wait
Orig
SMT027/
028 in
Approve
Cancel
Refuse
Approved?
Service
Rejected
Queue
Orig
SMT027/
028 back to
previous
status
Refuse
Approved cancelation
Orig
SMT038 in
Rejected
Orig
SMT038 in
Complete
Approved
cancelation
Orig Message
SMT027/028
Cancellation
flow
Accounting
(Reversal)
Posting Request
Core Banking
Posting
Response
Interbank or
Intrabank?
Interbank
Liquidity
Update
Intrabank
Phase
Canceled
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.
Global PAYplus Business Guide
Page 47
Clearing Processing
Generic Clearing Processing
2. Cancellation: An authorized user can refuse or approve the cancellation of the original MT198027/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
2.4.2.2.4
From the Service Release queue, the user can click Release to release the advice, which
indicates that the message was reviewed.
Accounting
This table shows the related accounting information for each flow and message sub type:
Flow
Message
Sub
Type
Accounting Model
Posting
Debit
account
Posting
Credit
account
Debit
Account
Credit
Account
Exception
Handling
PreSettlement
Advice –
Debit
SMT027/
028
Two Step
Accounting
– Presettlement
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 PreSettlement
advice
SMT036
One Step
Accounting
– Post
settlement
Customer
Account
ESA
Account
Customer
Account
ESA
Account
N/A
Global PAYplus Business Guide
Page 48
Clearing Processing
Generic Clearing Processing
Flow
Message
Sub
Type
Accounting 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
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.
Global PAYplus Business Guide
Comment
Page 49
Clearing Processing
Generic Clearing Processing
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
2.4.2.3.1.2
No wait for ACK or Confirmation is required to
continue processing.
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
Global PAYplus Business Guide
Page 50
Clearing Processing
Generic Clearing Processing
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
2.4.3.1
New Zealand - HVCS
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.
Global PAYplus Business Guide
Page 51
Clearing Processing
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 52
Clearing Processing
2.4.3.2
Generic Clearing Processing
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
2.4.3.3.1
Inward/Outward Processing
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:
Global PAYplus Business Guide
Page 53
Clearing Processing
Generic Clearing Processing
•
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
Name
HVCS
Calendar
Relevant calendar
or no value
Global PAYplus Business Guide
Comment
Page 54
Clearing Processing
Generic Clearing Processing
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
Cut-off name
HVCS_cust
HVCS_B2B
Cut-off type
Clearing
Clearing
Time zone
NZ
NZ
Global PAYplus Business Guide
Comment
Time zone for aligning cut-off
times
Page 55
Clearing Processing
Generic Clearing Processing
Field
HVCS for Customer
Payment
HVCS for Bank to
Bank Payments
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
Comment
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
MOP
HVCS
2.4.3.4.1.5
Comment
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 Immediately
Not selected
Hold x minutes before
pay-by- time
Select to define number of minutes (delta) from pay-bytime (CLS as accepted in Field 13 or 72) to process the
payment
Process
Global PAYplus Business Guide
Page 56
Clearing Processing
2.4.3.4.2
2.4.3.4.2.1
Generic Clearing Processing
Rules
MOP Selection
Rule
Name
Description
Attache
d to
HVCS
HVCS MOP
selection rule
Local
office
2.4.3.4.2.2
AND
/
OR
Field/Fiel
d
Operator
Value/
Field/
Function
Action
[Sttlm ccy]
=
NZD
Set
MOP to
HVCS
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
WINTER
_SCHED
Base
condition for
winter cut-off
period
NZ2
AN
D/
OR
Field/Field
Oper
ator
Value/Field
/Function
(
DATE_EXTRACT(Y
EAR,[P_CREATE_
DT])
=
2014
(
(
DATE_EXTRACT(D
AY,[P_CREATE_DT
]
>=
5
)
DATE_EXTRACT(M
ONTH,[P_CREATE
_DT])
=
10
)
DATE_EXTRACT(M
ONTH,[P_CREATE
_DT])
>
10
)
)
DATE_EXTRACT(Y
EAR,[P_CREATE_
DT]
=
2015
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
[Cdt MOP]
=
HVCS
BASE_CONDITION
(WINTER_SCHED)
=
TRUE
and
and
or
(
or
and
HVCS_
CLS
Clearing cut
off selection
for HVCS
NZ2
Global PAYplus Business Guide
OR
(
Actio
n
)
)
HVCS
_
CLS_
Page 57
Clearing Processing
Rule
Name
Description
_WINTE
R
MOP- CLS
winter
payments
HVCS_
CLS_
SUMME
R
Clearing cut
off selection
for HVCS
MOP- CLS
summer
payments
HVCS_
CUST
2.4.3.4.2.3
Generic Clearing Processing
Attache
d to
AN
D/
OR
Field/Field
Oper
ator
Value/Field
/Function
Actio
n
AN
D
Msg type
Cont
ains
SWIFT_2
WINT
ER
[Cdt MOP]
=
HVCS
or
BASE_CONDITION
(WINTER_SCHED)
=
FALSE
AN
D
[Orgnl sttlm CLS
Time]
Is not
Empty
HVCS
_
CLS_
SUM
MER
AN
D
Msg type
Cont
ains
SWIFT_2
[Cdt MOP]
=
HVCS
Msg type
=
SWIFT_103
HVCS
_
CUST
NZ2
Clearing cut
off selection
for HVCS
MOPcustomer
payments
NZ2
and
Office SLA
Office SLA Rule (182) allows for a SLA profile to be assigned to the payment.
Rule
Name
Descriptio
n
Attache
d to
HVCS
Sending
CLS
payments
on time
NZ2
2.4.4
2.4.4.1
AND
/ OR
Field/Field
Oper
ator
Value/Field
/Function
Actio
n
Sttlm CLS Time
Is not
Empty
HVCS
_SLA
Hong Kong - CHATS
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.
Global PAYplus Business Guide
Page 58
Clearing Processing
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 59
Clearing Processing
•
Generic Clearing Processing
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
System Parameters
Additional Information
N/A
Global PAYplus Business Guide
Page 60
Clearing Processing
Generic Clearing Processing
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
MOP Business
Date
Current business
day for the MOP
Value date
extension
0
Currency
HKD
Settlement
accounting
HKL settlement
account
Membership
Required
Must be selected
Membership type
MOP
Membership check
level
Metro
Global PAYplus Business Guide
If no calendar is assigned, the default calendar for the
office is used.
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.
BIC-8 level (Metro)
Page 61
Clearing Processing
Generic Clearing Processing
Field
Value for HK
CHATS
Send outgoing
message
Must be selected
Settlement
account exists
Must be selected
Comment
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
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
Global PAYplus Business Guide
Comment
Page 62
Clearing Processing
Generic Clearing Processing
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
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
Comment
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
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
UTC/GMT +8 hours
2.4.4.4.1.3.2 RMB CHATS
Field
Value for
RMB CHATS
Department
HKB
Global PAYplus Business Guide
Comment
Page 63
Clearing Processing
Generic Clearing Processing
Field
Value for
RMB CHATS
Office
HK1
Cut-off name
CHATSRMB
Cut-off type
Clearing
Time zone
HKT
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
Comment
UTC/GMT +8 hours
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
Department
HKB
Office
HK1
MOP
CHATSHKD/
CHATSUSD/
CHATSRMB
Comment
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
Global PAYplus Business Guide
Page 64
Clearing Processing
2.4.4.4.2
Generic Clearing Processing
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
CHATSR
MB
MOP
Selection for
CHATSRM
B
HK1
CHATSU
SD
MOP
Selection for
CHATSRM
B
HK1
MOP
Selection for
CHATSRM
B
HK1
CHATSH
KD
2.4.4.4.2.2
Rule
Name
AND/
OR
Field/Field
Operator
Value/
Field/
Function
Action
[Sttlm Ccy]
=
RMB
[Cdtr Agt
ctry]
=
HK
Set
CHATS
RMB
[Sttlm Ccy]
=
USD
[Cdtr Agt
ctry]
=
HK
[Sttlm Ccy]
=
HKD
AND
[Cdtr Agt
ctry]
=
HK
AND/
OR
Field/Field
Operator
Value/
Field/
Function
Action
AND
AND
Set
CHATS
USD
Set
CHATS
HKD
Clearing Cut off Rule
Rule
Sub
Type
Description
Attached
to
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
Global PAYplus Business Guide
Page 65
Clearing Processing
Rule
Name
Rule
Sub
Type
CHATSR
MBCUTO
FF
2.4.4.4.2.3
Generic Clearing Processing
Description
Attached
to
Clearing cut
off selection
for
CHATSRM
B MOP
HK1
AND/
OR
Field/Field
Operator
Value/
Field/
Function
Action
[Cdt MOP]
In
CHATSH
KD
Set
CHATS
RMB
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
Description
Attached
to
MISSED
CHATSU
SDCLEA
R
Missed
clearing cutoff for
CHATSUSD
bank
payments
HK1
MISSED
CHATSH
KDCLEA
R
Missed
clearing cutoff for
CHATSHKD
bank
payments
HK1
MISSED
CHATSR
MBCLEA
R
Rule
Sub
Type
Missed
clearing cutoff for
CHATSRM
B bank
payments
Global PAYplus Business Guide
HK1
AND/
OR
Field/Field
Operator
Value/
Field/
Function
Action
[Cdt MOP]
=
CHATS
USD
MAN_CL
EARING
[Msg tp]
In
SWIFT_
202,SW
IFT_202
COV
[Cdt MOP]
=
CHATS
HKD
[Msg tp]
In
SWIFT_
202,SW
IFT_202
COV
[Cdt MOP]
=
CHATS
RMB
[Msg tp]
In
SWIFT_
202,SW
IFT_202
COV
MAN_CL
EARING
MAN_CL
EARING
Page 66
Clearing Processing
2.4.5
2.4.5.1
Generic Clearing Processing
Singapore - MEPS
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 nonparticipating 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.
Global PAYplus Business Guide
Page 67
Clearing Processing
2.4.5.2
Generic Clearing Processing
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
Global PAYplus Business Guide
Page 68
Clearing Processing
2.4.5.4.4
Generic Clearing Processing
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+
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+
Global PAYplus Business Guide
Comment
Page 69
Clearing Processing
2.4.5.5.1.2
Generic Clearing Processing
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+
Cut-off name
MEPS
Cut-off type
Clearing
Time zone
SGT
Description
MEPSPLUS Clearing
Cut-off
Comment
Time zone for aligning cut-off times
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+
MOP
MEPS
Type of
Membership
Full member for
MEPS+ participants
(or associates)
2.4.5.5.1.3
Comment
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+
MOP
MEPS
2.4.5.5.2
Comment
Rules
These are examples of user defined rules.
2.4.5.5.2.1
MOP Selection
Global PAYplus Business Guide
Page 70
Clearing Processing
Generic Clearing Processing
Rule
Name
Rule
Sub
Type
Description
Attached
to
MEPS
PLUS
N/A
MEPSPLUS
MOP
selection rule
Local
office
2.4.5.5.2.2
AND/
OR
Field
Operator
Value/
Field/
Function
Action
[Sttl
m
Ccy]
=
SGD
AND
[Msg
tp]
IN
SWIFT_1
03,
SWIFT_2
02
SET MOP
Profile
MEPSPLU
S
AND
[Cdtr
Agt
ctry]
=
SG
AND/
OR
Field
Operator
Value/
Field/
Function
Action
[Cdt
MOP
]
=
MEPSPL
US
SET
MEPSPLU
S cut off
(19:00)
Clearing Cut Off
Rule
Name
Rule
Sub
Type
Description
Attached
to
MEPS
PLUS
N/A
MEPSPLUS
cut off
selection rule
Local
office
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
MEPS
PLUS
OPEN
TIME
N/A
MEPSPLUS
opening time
Local
office
2.4.6
2.4.6.1
AND/
OR
Field
Operator
Value/
Field/
Function
Action
[Cdt
MOP
]
=
MEPSPL
US
SET Hold
until time to
06:00 AM
Malaysia - RENTAS
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.
Global PAYplus Business Guide
Page 71
Clearing Processing
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 72
Clearing Processing
2.4.6.2
Generic Clearing Processing
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.
Global PAYplus Business Guide
Page 73
Clearing Processing
Generic Clearing Processing
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
Global PAYplus Business Guide
Page 74
Clearing Processing
Generic Clearing Processing
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).
Global PAYplus Business Guide
Page 75
Clearing Processing
•
Generic Clearing Processing
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).
Global PAYplus Business Guide
Page 76
Clearing Processing
3
Mass Payment Clearings
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
3.1.1.1.3.1
Cutoffs (Determination of Final Balances)
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.
Global PAYplus Business Guide
Page 77
Clearing Processing
Mass Payment Clearings
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
SEPA Credit
Transfer (SCT)
3.1.1.2
Message Type
Description
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.
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
Global PAYplus Business Guide
Page 78
Clearing Processing
3.1.1.2.2
Mass Payment Clearings
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
Global PAYplus Business Guide
Page 79
Clearing Processing
Mass Payment Clearings
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
3.1.1.3.1
Inward/Outward Processing
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)
Global PAYplus Business Guide
Page 80
Clearing Processing
•
•
Cut-offs with immediate settlement (only D):
o
12.45 p.m. (X0X12)
o
3.00 p.m. (X0X15)
Pure Settlement (only D):
o
•
•
Mass Payment Clearings
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
Global PAYplus Business Guide
Page 81
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 82
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 83
Clearing Processing
•
Mass Payment Clearings
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 revaluation 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
Global PAYplus Business Guide
Page 84
Clearing Processing
Mass Payment Clearings
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
Global PAYplus Business Guide
Page 85
Clearing Processing
Mass Payment Clearings
3.2 Mass Payment Africa Clearing
3.2.1
3.2.1.1
South Africa - AC
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.
Global PAYplus Business Guide
Page 86
Clearing Processing
Mass Payment Clearings
Weekdays (Monday to Friday) Operating Hours
Saturday, Sunday and Public Holidays Operating Hours
Global PAYplus Business Guide
Page 87
Clearing Processing
3.2.1.1.2
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 88
Clearing Processing
3.2.1.2
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 89
Clearing Processing
Mass Payment Clearings
AC_MP_1.1 - Outward Direct Debit via AC Clearing
Channel/
GPP Integration
Initiating Party
Incoming Customer
file (pain.008)
Can be wrapped
with Fundtech Msg
Receipt file
Creditor Bank’s
GPP MP Processing
GPP User
Bank’s Core
Systems
Clearing Gateway
Clearing
Service
Debtor Bank
File processing
Pre-Processing
Transactions
Customer
Acknoledge
ment
Send file
Sub-batch
generation
Sub-batch
Completion
Individual tx
in Wait
Confirmation
Outward
Direct Debit
(Pacs.003)
Inward file
identification
and matching
Set Status of
all
transactions
Receipt file
Outward
Direct Debit
File in
Complete
RJCT
(Rejected)
Status
Report file
(Pacs.002)
Clearing
Validations
Individual tx
in Rejected
End
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.
Global PAYplus Business Guide
Page 90
Clearing Processing
Mass Payment Clearings
AC_MP_1.2 - Outward Direct Debit via AC Clearing
Channel/
GPP Integration
Initiating Party
Incoming Customer
file (pain.008)
Can be wrapped
with Fundtech Msg
Receipt file
Creditor Bank’s
GPP MP Processing
GPP User
Bank’s Core
Systems
Clearing Gateway
Clearing
Service
Debtor Bank
File processing
Pre-Processing
Transactions
Customer
Acknoledge
ment
Send file
Sub-batch
generation
Sub-batch
Completion
Individual tx
in Wait
Confirmation
Outward
Direct Debit
(Pacs.003)
Inward file
identification
and matching
Set Status of
all
transactions
Receipt file
Outward
Direct Debit
File in
Complete
RJCT
(Rejected)
Status
Report file
(Pacs.002)
Clearing
Validations
Individual tx
in Rejected
End
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.
Global PAYplus Business Guide
Page 91
Clearing Processing
3.2.1.2.1.3
Mass Payment Clearings
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
Channel/
GPP Integration
Initiating Party
Incoming
Customer file
(pain.008)
Can be wrapped
with Fundtech Msg
Receipt file
Creditor Bank’s
GPP MP Processing
GPP User
Bank’s Core
Systems
Clearing Gateway
Clearing
Service
Debtor Bank
File processing
Pre-Processing
Transactions
Customer
Acknoledge
ment
Send file
Sub-batch
generation
Sub-batch
Completion
Individual tx
in Wait
Confirmation
Outward
Direct Debit
(Pacs.003)
Inward file
identification
and matching
Receipt file
Outward
Direct Debit
File in
Complete
ACCP (Accepted) or
ACWC (Accepted With
Change)
Status Report file
(Pacs.002)
Clearing
Validations
Clearing
processing &
formatting
Outward Direct
Debit file
(Pacs.003)
Direct Debit
validations &
processing
RJCT
(Rejected)
Outward Debit Response
(Pacs.002)
Inward file
identification
and matching
Clearing
Validations
& processing
RJCT
(Rejected)
Outward Debit Response
(Pacs.002)
Transaction
matching
Set
transaction
Status
Individual tx
in Rejected
End
Global PAYplus Business Guide
Page 92
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 93
Clearing Processing
Mass Payment Clearings
AC_MP_1.4 - Outward Direct Debit via AC Clearing
Channel/
GPP Integration
Initiating Party
Incoming Customer
file (pain.008)
Can be wrapped
with Fundtech Msg
Receipt file
Creditor Bank’s
GPP MP Processing
GPP User
Bank’s Core
Systems
Clearing Gateway
Clearing
Service
Debtor Bank
File processing
Pre-Processing
Transactions
Customer
Acknoledge
ment
Send file
Sub-batch
generation
Sub-batch
Completion
Individual tx
in Wait
Confirmation
Outward
Direct Debit
(Pacs.003)
Receipt file
Outward
Direct Debit
File in
Complete
Inward file
identification
and matching
ACCP (Accepted) or
ACWC (Accepted With
Change)
Status Report file
(Pacs.002)
Clearing
Validations
Clearing
processing &
formatting
Outward Direct
Debit file
(Pacs.003)
Direct Debit
validations &
processing
PDNG
(Pending)
Outward Debit Response
(Pacs.002)
Inward file
identification
and matching
Clearing
Validations
& processing
PDNG
(Pending)
Outward Debit Response
(Pacs.002)
Transaction
matching
Set
transaction
Status
Individual tx
in Pending
Debit
Confirmation
End
Global PAYplus Business Guide
Page 94
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 95
Clearing Processing
3.2.1.2.2.2
Mass Payment Clearings
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
Creditor Bank
Clearing
Service
Clearing Gateway
Bank’s Core
Systems
GPP User
Outward
Direct Debit
file
(Pacs.003)
Debtor Bank’s
GPP MP Processing
GPP Integration
File processing
Pre-Processing
Transactions
Sub-batch
generation
Individual tx
in Complete
Sub-batch
Completion
Generate Debit
Response
(Pacs.002)
Transaction
ACSC
(Accepted, Settlement
Complete)
Outward Debit Response
(Pacs.002)
Receipt file
Clearing
validations
Inward Status
Report file in
Complete
ACCP (Accepted)
Status Report file
(Pacs.002)
Inward file
identification
and matching
Clearing
processing &
formatting
End
Receipt file
ACSC
(Accepted, Settlement
Complete)
Outward Debit Response
(Pacs.002)
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.
Global PAYplus Business Guide
Page 96
Clearing Processing
Mass Payment Clearings
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
Creditor Bank
Clearing
Service
Clearing Gateway
Bank’s Core
Systems
GPP User
Outward
Direct Debit
file
(Pacs.003)
Debtor Bank’s
GPP MP Processing
GPP Integration
File processing
Individual tx
in Rejected
Pre-Processing
Transactions
Generate Debit
Response
(Pacs.002)
Transaction
RJCT
(Reject)
Outward Debit Response
(Pacs.002)
Receipt file
Clearing
validations
Inward Status
Report file in
Complete
ACCP (Accepted)
Status Report file
(Pacs.002)
Inward file
identification
and matching
Clearing
processing &
formatting
End
Receipt file
RJCT
(Reject)
Outward Debit Response
(Pacs.002)
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.
Global PAYplus Business Guide
Page 97
Clearing Processing
Mass Payment Clearings
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
Creditor Bank
Clearing
Service
Clearing Gateway
Bank’s Core
Systems
Debtor Bank’s
GPP MP Processing
GPP User
Outward
Direct Debit
file
(Pacs.003)
GPP Integration
File processing
Pre-Processing
Transactions
Sub Batch
Generation
Accounting System
Posting Request (DrDebtor)
Sub Batch
Completion
Posting Response NSF
Schedule
Rejected
Yes
D_Max_Debit_Rtry_Date>
Business Date
PNDG
(Pending)
Outward Debit Response
(Pacs.002)
No
RJCT
(Reject)
Outward Debit Response
(Pacs.002)
Receipt file
Clearing
validations
Yes
Inward Status
Report file in
Complete
ACCP (Accepted)
Status Report file
(Pacs.002)
Inward file
identification
and matching
Clearing
processing &
formatting
End
Receipt file
RJCT
(Reject)
Outward Debit Response
(Pacs.002)
Details of the flow:
1. AC clearing triggers a Direct Debit payment instruction (pacs.003) in a file to a debtor bank.
Global PAYplus Business Guide
Page 98
Clearing Processing
Mass Payment Clearings
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
3.2.1.3.1
Outward/Inward Processing
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
Global PAYplus Business Guide
Page 99
Clearing Processing
3.2.1.3.1.2
Mass Payment Clearings
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
()
Original Message ID
()
•
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
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 ( 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.
Global PAYplus Business Guide
Page 100
Clearing Processing
Mass Payment Clearings
•
When the direct debit (pacs.003) is rejected by AC clearing, the group level status is Rejected
( 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 ( 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
()
Original Transaction ID
()
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 ( 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.
Global PAYplus Business Guide
Page 101
Clearing Processing
Mass Payment Clearings
•
GPP identifies the transaction level status as Pending ( 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 ( 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 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 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.
Global PAYplus Business Guide
Page 102
Clearing Processing
Mass Payment Clearings
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 () 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
Global PAYplus Business Guide
Page 103
Clearing Processing
Field
Mass Payment Clearings
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
Global PAYplus Business Guide
Page 104
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 105
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 106
Clearing Processing
Mass Payment Clearings
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
1
2
3
Rule Attribute
Setup Guidelines
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
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
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
Global PAYplus Business Guide
Page 107
Clearing Processing
Rule
Rule Attribute
Mass Payment Clearings
Setup Guidelines
• The message is outward to AC (credit MOP =
AC)
Clearing Cut off profile to be selected:
AC_DD_MP_COTPCS2
Action
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
1
2
3.2.1.4.2.3
Rule Attribute
Setup Guidelines
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
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
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:
Global PAYplus Business Guide
Page 108
Clearing Processing
Mass Payment Clearings
Rule
Rule Attribute
1
Outgoing group ID for outward Direct Debit (pacs.003) sent to AC
2
Setup Guidelines
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
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
Global PAYplus Business Guide
Page 109
Clearing Processing
Mass Payment Clearings
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
3.3.1.1
Malaysia - IBG
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
Global PAYplus Business Guide
Page 110
Clearing Processing
•
Mass Payment Clearings
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
SWIFT 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:
Global PAYplus Business Guide
Page 111
Clearing Processing
3.3.1.1.2
Mass Payment Clearings
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).
2.
Payer authorize
authorize DD
DD
2. Payer
instruction
instruction to
to Biller
Biller
4. DDA Approval
1. Biller Registration
Payer
3. Biller register Payer’s DDA in DDA DMS via Biller Bank
DDA DMS
IBG DD Txn
(Debit Normal)
5. IBG DD Txn
(Debit Normal)
IBG System
DDI
Biller
Biller Bank
IBG DD Txn
(Debit Return)
IBG DD Txn
(Debit Return)
Payer Bank
DDS
Mandates
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.
Global PAYplus Business Guide
Page 112
Clearing Processing
Message Type
Mass Payment Clearings
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
Global PAYplus Business Guide
Page 113
Clearing Processing
3.3.1.2.1
Mass Payment Clearings
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:
Global PAYplus Business Guide
Page 114
Clearing Processing
Mass Payment Clearings
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
Biller
Biller Bank
Start
My Clear
Payer
4
Status
(DR)
Complie and
Generate IBG File
3
2
IBG System
IBG DD File
(DN)
1
Payer Bank
Distribute
(DN)
Mandate Checking
and Debit Payer
DDI
Credit Biller
Account
5
Status
(DR)
Phase
Submit DDI File
Global PAYplus Business Guide
Page 115
Clearing Processing
3.3.1.2.1.2
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 116
Clearing Processing
Mass Payment Clearings
Outgoing DN to MyClear from Biller Bank – Incoming DR R99 response – IBGDD-DDO-DN-3.1.2
Channel/
Initiating Party
GPP Integration
Receive File
Pain.008
GPP (Biller Bank)
Pain.008
GPP User
Bank’s Core System
GPP Clearing
Integration
MyClear
In File
Processing
Pre-processing
(Individual
Transactions DN)
Sub Batch
Completion –
Execution
Individual
Sub Batch
Completion –
Execution
Bulking Profile
(I)
Wait
Confirmation
Cancel
After Match DR R99
Rejected
Out File
Generation
Out DN
Clearing
Processing and
Formatting
Send File
In File
Processing
Outgoing
Collection File Collection
(Out DN) file (NACHA)
In DR – R99
Receive File
Pre-processing
(Individual
Transactions DR)
Distribution File
(In DR)
Matching IN
DR with Out
DN
Complete
Phase
Sub Batch
Completion –
Execution
Individual
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.
Global PAYplus Business Guide
Page 117
Clearing Processing
Mass Payment Clearings
Outgoing DN (future dated) from Biller – IBGDD-DDO-DN-3.1.3
Channel/
Initiating Party
Pain.008
GPP Integration
Receive File
GPP (Biller Bank)
GPP User
Bank’s Core System
GPP Clearing
Integration
MyClear
In File
Processing
Pain.008
Future Date
VD > BD
Schedule
Phase
Pre-processing
(Individual
Transactions DN)
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
Pain.008
GPP Integration
Receive File
GPP (Biller Bank)
Pain.008
GPP User
Bank’s Core System
GPP Clearing
Integration
MyClear
In File
Processing
Failed
Rejected
Phase
Pre-processing
(Individual
Transactions DN)
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.
Global PAYplus Business Guide
Page 118
Clearing Processing
Mass Payment Clearings
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 DebitRetry 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.
Global PAYplus Business Guide
Page 119
Clearing Processing
Mass Payment Clearings
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
Global PAYplus Business Guide
Page 120
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 121
Clearing Processing
Mass Payment Clearings
Incoming DN from MyClear to Payer Bank – Debit Retry Scheduled – No response to MyClear - IBGDD-DDI-DN-3.2.3
MyClear
GPP Clearing Services
Incoming
Distribution
file (NACHA)
Receives File
GPP MP Processing
GPP Users
Bank’s Core System
Payer
In File
Processing
Pre-processing
(Individual
Transactions DN)
D_Debit_Rtry_Days mapping
D_Max_Debit_Rtry_Date calculation
Mandate Checking
Sub Batch
Completion –
Execution (I)
Hold until time (optional)
Sub Batch
Completion –
Execution
Individual
Posting Request (Dr Payer)
Accounting System
Posting Response
Posting Successful ?
NSF response
D_Max_Debit_Rtry_Date >
Business Date
Yes
Schedule
FT Std Advice for next day retry
[Termination Flow]
Phase
Payer
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 nontransaction 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.
Global PAYplus Business Guide
Page 122
Clearing Processing
3.3.1.2.2.4
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 123
Clearing Processing
Mass Payment Clearings
Outgoing DN to MyClear from Biller Bank – Incoming DR R00 response – IBGDD-DDO-DN-3.1.1
Channel/
Initiating Party
GPP Integration
Pain.008
Receive File
GPP (Biller Bank)
Pain.008
GPP User
Bank’s Core System
GPP Clearing
Integration
MyClear
In File
Processing
Pre-processing
(Individual
Transactions DN)
Sub Batch
Completion –
Execution
Individual
Sub Batch
Completion –
Execution
Bulking Profile
(I)
Wait
Confirmation
Cancel
After Match DR R00
Complete
Out File
Generation
Clearing
Processing and
Formatting
Out DN
Send File
In File
Processing
Outgoing
Collection File Collection
(Out DN) file (NACHA)
In DR – R00
Receive File
Pre-processing
(Individual
Transactions DR)
Distribution File
(In DR)
Matching IN
DR with Out
DN
Sub Batch
Generation (S)
Sub Batch
Completion –
Execution
Individual
Accounting System
Complete
Batch Posting
Dr BSA
Cr Biller
(Lump sum/Itemized)
Accounting System
Phase
Posting Task
Online Posting (S)
Dr Clearing (lump sum)
Cr BSA (lump sum)
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.
Global PAYplus Business Guide
Page 124
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 125
Clearing Processing
Mass Payment Clearings
Outgoing DN to MyClear from Biller Bank – Incoming DR R99 response – IBGDD-DDO-DN-3.1.2
Channel/
Initiating Party
GPP Integration
Receive File
Pain.008
GPP (Biller Bank)
Pain.008
GPP User
Bank’s Core System
GPP Clearing
Integration
MyClear
In File
Processing
Pre-processing
(Individual
Transactions DN)
Sub Batch
Completion –
Execution
Individual
Sub Batch
Completion –
Execution
Bulking Profile
(I)
Wait
Confirmation
Cancel
After Match DR R99
Rejected
Out File
Generation
Out DN
Clearing
Processing and
Formatting
Send File
In File
Processing
Outgoing
Collection File Collection
(Out DN) file (NACHA)
In DR – R99
Receive File
Pre-processing
(Individual
Transactions DR)
Distribution File
(In DR)
Matching IN
DR with Out
DN
Complete
Phase
Sub Batch
Completion –
Execution
Individual
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.
Global PAYplus Business Guide
Page 126
Clearing Processing
Mass Payment Clearings
Outgoing DN (future dated) from Biller – IBGDD-DDO-DN-3.1.3
Channel/
Initiating Party
Pain.008
GPP (Biller Bank)
GPP Integration
Receive File
GPP User
Bank’s Core System
GPP Clearing
Integration
MyClear
In File
Processing
Pain.008
Future Date
VD > BD
Schedule
Phase
Pre-processing
(Individual
Transactions DN)
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 preprocessing 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
Pain.008
GPP Integration
Receive File
GPP (Biller Bank)
Pain.008
GPP User
Bank’s Core System
GPP Clearing
Integration
MyClear
In File
Processing
Failed
Rejected
Phase
Pre-processing
(Individual
Transactions DN)
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).
Global PAYplus Business Guide
Page 127
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 128
Clearing Processing
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 129
Clearing Processing
3.3.1.2.5.2
Mass Payment Clearings
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.
Global PAYplus Business Guide
Page 130
Clearing Processing
Mass Payment Clearings
Incoming DN from MyClear to Payer Bank – Debit Retry Scheduled – No response to MyClear - IBGDD-DDI-DN-3.2.3
MyClear
GPP Clearing Services
Incoming
Distribution
file (NACHA)
Receives File
GPP MP Processing
GPP Users
Bank’s Core System
Payer
In File
Processing
Pre-processing
(Individual
Transactions DN)
D_Debit_Rtry_Days mapping
D_Max_Debit_Rtry_Date calculation
Mandate Checking
Sub Batch
Completion –
Execution (I)
Hold until time (optional)
Sub Batch
Completion –
Execution
Individual
Posting Request (Dr Payer)
Accounting System
Posting Response
Posting Successful ?
NSF response
D_Max_Debit_Rtry_Date >
Business Date
Yes
Schedule
FT Std Advice for next day retry
[Termination Flow]
Phase
Payer
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.
Global PAYplus Business Guide
Page 131
Clearing Processing
3.3.1.2.5.4
Mass Payment Clearings
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
3.3.1.2.7.1
Mandate Validation
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)
Global PAYplus Business Guide
Page 132
Clearing Processing
•
Mass Payment Clearings
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).
Global PAYplus Business Guide
Page 133
Clearing Processing
Mass Payment Clearings
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 nonbusiness 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.
Global PAYplus Business Guide
Page 134
Clearing Processing
3.3.1.3
Mass Payment Clearings
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
Latest Value Date
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
Global PAYplus Business Guide
Page 135
Clearing Processing
Mass Payment Clearings
This profile is used as an identifier IBG DD transactions.
Field
Value for IBG
MOP
MYIBGDD
Currency
MYR
Identifier
Default ID for MOP office
Checked
Default office for ID
Checked
Settlement Account Office
DHM
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
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.
Global PAYplus Business Guide
Page 136
Clearing Processing
Mass Payment Clearings
Field
Value for IBG
Department
DHM
Office
DHM
Clearing System ID
MYIBG
Member ID
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
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
Creditor ID
Validate DD Creditor ID Account
Validate DD creditor ID
False
Validate DD creditor ID
Account
False
Management Parameters
Mandate management
option
3.3.1.3.1.9
Unchecked
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
Global PAYplus Business Guide
Page 137
Clearing Processing
Mass Payment Clearings
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
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
Global PAYplus Business Guide
Page 138
Clearing Processing
3.3.1.3.2
Mass Payment APAC Clearing
Rules
3.3.1.3.2.1
MOP Selection Rule
Rule
Rule Attribute
1
Assign MYIBGDD MOP for all pain.008 files
2
Setup Guidelines
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
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
1
Accepts files received for correct RFI; rejects files not designated for correct RFI.
3.3.1.3.2.3
Setup Guidelines
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] <>
Action
Rejected
Clearing Cut-off Rule
Rule
Rule Attribute
1
Clearing cut off for IBGDD transactions
Setup Guidelines
Rule Name
MYIBG_DD_MP_CC
Attachment
DHM
Global PAYplus Business Guide
Page 139
Clearing Processing
Rule
Rule Attribute
Setup Guidelines
Rule conditions
All of the following conditions should be met:
[Cdt MOP] = MYIBGDD
MYIBGD_CC
Action
3.3.1.3.2.4
Debit Transaction Code Rule
Rule
Rule Attribute
1
Default code for debit transactions
Rule
Setup Guidelines
Rule Name
MP_DD_DR_TC
Attachment
DHM
Rule conditions
All of the following conditions should be met:
[Cdt MOP] = MYIBGDD
DEF_DR
Action
3.3.1.3.2.5
Mass Payment APAC Clearing
Credit Transaction Code Rule
Rule Attribute
Setup Guidelines
Default code for credit transactions
1
Rule Name
MP_DD_CR_TC
Attachment
DHM
Rule conditions
Action
3.3.1.3.2.6
DEF_CR
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
1
Bypass fees for Inward IBG transactions
3.3.1.3.2.7
Rule
Setup Guidelines
Rule Name
MYIBG_DD_MP_BYPASS_FEE
Attachment
DHM
Rule conditions
All of the following conditions should be met:
[File Source] = MYIBGDD
Action
BYPASS
Advising Type Selection Rule
Rule Attribute
Setup Guidelines
Setup guidelines for selecting advising type
1
Rule Name
MYIBG_DD_MP_DR_ADV
Attachment
DHM
Global PAYplus Business Guide
Page 140
Clearing Processing
Rule
Mass Payment APAC Clearing
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
ADVISING
Action
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
1
File duplicate checking for Incoming Distribution File from MyClear
Rule Name
Setup Guidelines
MYIBG_DD_MP_FILE_DUPL
Attachment
Rule conditions
Action
2
All of the following conditions should be met:
F_FILE_SOURCE = MYIBGDD
MYIBG_DD_MP_FILE_DUPL
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
3.3.1.3.2.10
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
Mandate Validation Rule
Global PAYplus Business Guide
Page 141
Clearing Processing
Mass Payment APAC Clearing
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
Global PAYplus Business Guide
Page 142
Clearing Processing
3.3.1.4
3.3.1.4.1
Mass Payment Clearings
STP Message Processing
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.
Global PAYplus Business Guide
Page 143
Clearing Processing
4
Distributed Ledger Payment Processing
Distributed Ledger Payment Processing
4.1 Clearing Processing on Distributed Payment Environment
4.1.1
4.1.1.1
Ripple
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.
Global PAYplus Business Guide
Page 144
Clearing Processing
Global PAYplus Business Guide
Distributed Ledger Payment Processing
Page 145
Clearing Processing
4.1.1.3
Distributed Ledger Payment Processing
Use Cases & Flow Processes
4.1.1.3.1
Request for ‘Get Quote’ from Ripple
Payment processing (instructing bank) – get quote
Other systems
GPP
Feeder / Manual
Process
payment
Pain.001
Ripple
Pefrom first compliance
Cdt MOP = Ripple
MOP exit point with get quote.
‘Get Quote’
request
Generate ‘Get
Quote’ Request
Status = Wait
Rate
‘Get quote’
response
Process quote
Copy details from response to payment:
Match response
to request
Retry
Quote
Status = Repair /
Quote Exception
false
q
q
q
q
Beneficiary details
Beneficiary side fees
Quote expiration date and time
Etc.
Success?
true
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.
Global PAYplus Business Guide
Page 146
Clearing Processing
4.1.1.3.2
Distributed Ledger Payment Processing
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
no
Generate
‘Accept quote’
request
‘Accept quote’
request
yes
Retry
Quote
Status = Wait
Confirmation
Status = Repair /
Quote Exception
‘Accept quote’
response
Process ‘Accept
quote’
Match response
to request
Retry
Quote
Status = Repair /
Quote Exception
false
Success?
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.
Global PAYplus Business Guide
Page 147
Clearing Processing
4.1.1.3.3
Distributed Ledger Payment Processing
Execute Payment to Ripple (Instructing Agent)
Payment processing (Instructing bank) – Execute payment
Feeder / Manual
GPP
Other systems
Ripple
2
‘Locked’
payments query
Get ‘locked’
payments
‘Locked’
Payments
For each payment
Load payment
(by ID)
yes
Compliance
check
Compliance
Exception
Queue
Compliance
check request
Success?
q
q
q
Dr debtor
Cr clearing suspense
Cr fee PNL
Status = posting
exception
Posting
no
Posting request
Posting OK?
yes
Status = wait
confirmation
Submit
[sending]
payment
Sending
payment
response
Sending
payment
Execute
payment
Match response
to request
failed
Status = NAK \
Rejected
State
Succeeded
In progress
Status = Wait
Confirmation
Status =
complete
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.
Global PAYplus Business Guide
Page 148
Clearing Processing
•
Distributed Ledger Payment Processing
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
‘Accepted’
payments query
Get ‘accepted’
payments
‘Accepted’
Payments
For each payment
Create payment
Validations
& processing
Status = Rejected?
no
q
q
q
q
q
q
Duplicate check
Dr MOP – Ripple
Source STP validation
Dr side processing
Cr side processing
Cr MOP book
Valid?
yes
Compliance
Status = Compliance
exception
no
Compliance
check request
Compliance
OK?
yes
Generate ‘Lock
quote’ request
Status = Wait Lock?
‘Lock quote’
response
‘Lock quote’
request
Process ‘Lockt
quote’
Match response
to request
Status = Repair /
Quote Exception
false
Success?
true
Status = locked? \
Release?
3
•
Receiving bank gets the payments that were accepted.
Global PAYplus Business Guide
Page 149
Clearing Processing
•
Distributed Ledger Payment Processing
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
Get ‘In
progress’
payments
‘In progress’
payments query
‘In progress’
Payments
For each payment
Load payment
(by ID)
q
q
q
Dr clearing suspense
Cr beneficiary
Cr fee PNL
Posting
Status = posting
exception
Posting request
Posting OK?
no
yes
Submit
[receiving]
payment
Status = Wait
confirmation?
Sending
payment
response
POST
Reciving
payment
Execute
payment
Match response
to request
failed
Status = ?
State
Succeeded
Status =
complete
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
Global PAYplus Business Guide
Page 150
Clearing Processing
Distributed Ledger Payment Processing
•
Completes processing and sends SMS to beneficiary
•
Changes status to Complete
4.1.1.4
Business Setup
Setup
System Parameters
N/A
Profiles
MOP Selection
Rules
N/A
Permissions
N/A
Tasks
N/A
queues
N/A
System Configuration
Interface profile
4.1.1.4.1
4.1.1.4.1.1
Additional Information
Profiles
Profiles
MOP Selection
On the initiating party a MOP Ripple should be defined
Field
Value for Ripple
Name
Ripple
Calendar
Relevant calendar or
no value
Comment
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.
Global PAYplus Business Guide
Page 151
Clearing Processing
Appendix A: Glossary
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
Global PAYplus Business Guide
Page 152
Clearing Processing
Appendix A: Glossary
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
Global PAYplus Business Guide
Page 153
Clearing Processing
Term
Appendix A: Glossary
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
Global PAYplus Business Guide
Page 154
Clearing Processing
Term
Appendix A: Glossary
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
Global PAYplus Business Guide
Page 155
Clearing Processing
Appendix A: Glossary
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
Global PAYplus Business Guide
Page 156
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Author : D+H Category : Global PAYplus Version 4.6.6 Comments : Company : COMMERCIAL IN CONFIDENCE Content Type Id : 0x01010037BB9CACCC7A0843BC34289099ED0E6E Create Date : 2017:06:19 13:19:48-04:00 Keywords : Global, PAYplus Modify Date : 2017:06:19 13:20:37-04:00 Source Modified : D:20170619171622 Subject : Clearing Processing Tag Check Out Src Url : https://dhcorp.sharepoint.com/sites/gpsil/PaymentsSbuIL/Product/DropOffLibrary/GPP-SP 4.6/Business Guides/GPP Business Guide Clearing Processing.docx Language : EN-US Tagged PDF : Yes XMP Toolkit : Adobe XMP Core 5.6-c015 84.159810, 2016/09/10-02:41:30 Metadata Date : 2017:06:19 13:20:37-04:00 Creator Tool : Acrobat PDFMaker 15 for Word Document ID : uuid:fe18b968-5a09-4a77-9f85-89abe54c50f4 Instance ID : uuid:4bae9fdf-4b13-4aa7-96a8-eea8370f42f8 Format : application/pdf Title : Business Guide Description : Clearing Processing Creator : D+H Producer : Adobe PDF Library 15.0 Headline : Clearing Processing Page Layout : OneColumn Page Mode : UseOutlines Page Count : 156EXIF Metadata provided by EXIF.tools