Business Guide GPP Message Types

User Manual: Pdf

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

Global PAYplus
Message Types
Business Guide
Product Version: 4.6.8
Catalog ID: GPP4.6-00-B49-03-201709
Copyright
© 2009 - 2018 Finastra International Limited, or a member of the Finastra group of companies (“Finastra”). All
Rights Reserved. Confidential - Limited Distribution to Authorized Persons Only, pursuant to the terms of the
license agreement by which you were granted a license from Finastra for the applicable software or services and
this documentation. Republication or redistribution, in whole or in part, of the content of this documentation or any
other materials made available by Finastra is prohibited without the prior written consent of Finastra. The
software and documentation are protected as unpublished work and constitute a trade secret of Finastra
International Limited, or a member of the Finastra group of companies, Head Office: One Kingdom Street,
Paddington, London W2 6BL, United Kingdom.
Disclaimer
Finastra does not guarantee that any information contained herein is and will remain accurate or that use of the
information will ensure correct and faultless operation of the relevant software, services or equipment. This
document contains information proprietary to Finastra. Finastra does not undertake mathematical research but
only applies mathematical models recognized within the financial industry. Finastra does not guarantee the
intrinsic theoretical validity of the calculation models used.
Finastra, its agents, and employees shall not be held liable to or through any user for any loss or damage
whatsoever resulting from reliance on the information contained herein or related thereto. The information
contained in this document and the general guidance of Finastra staff does not take the place of qualified
compliance personnel or legal counsel within your institution.
FINASTRA CANNOT RENDER LEGAL, ACCOUNTING OR OTHER PROFESSIONAL SERVICES TO YOUR
INSTITUTION. THE INFORMATION CONTAINED HEREIN IS GENERAL IN NATURE AND DOES NOT
CONSTITUTE LEGAL ADVICE OR A LEGAL OPINION. CONSULT YOUR LEGAL COUNSEL FOR LEGAL
ADVICE SPECIFIC TO YOUR SITUATION OR CIRCUMSTANCES OR TO ANSWER ANY LEGAL
QUESTIONS.
This document is not intended as a substitute for formal education in the regulatory requirements of banking,
banking operations, lending, lending operations, or other topics generally applicable to financial institutions. Your
financial institution is solely responsible for configuring and using the software or services in a way that meets
policies, practices, and laws applicable to your institution, including, without limitation: (1) options and selections
made on prompts; (2) entries in the software program; (3) program setup; and (4) documents produced by the
software or services. It is the obligation of the customer to ensure that responsible decisions are taken when
using Finastra products. Information in this document is subject to change without notice and does not represent
a commitment on the part of Finastra.
Feedback
Do you have comments about our guides and online help? Please address any comments and questions to your
local Finastra representative.
Need more information? Read more about our products at http://www.finastra.com or contact your local Finastra
office at http://www.finastra.com/contact.
Global PAYplus | Message Types | Business Guide Page 3
Version Control
Version
Date
Summary of Changes
1.0
Document Created
2.0
Mar 2016
Added MT102, MT203, and MT204
3.0
April 2017
Added new section for ISO 2022 Processing, camt.054
Global PAYplus | Message Types | Business Guide Page 4
Table of Contents
1 INTRODUCTION .................................................................................................................... 5
1.1 Overview .......................................................................................................................... 5
1.2 SWIFT Messages............................................................................................................. 6
1.3 ISO 20022 Message Standards ........................................................................................ 8
1.4 Target Audience ............................................................................................................... 8
2 SWIFT PROCESSING ............................................................................................................ 8
2.1 MT101 Message .............................................................................................................. 8
2.1.1 Overview ...................................................................................................................... 9
2.1.2 Processing.................................................................................................................. 10
2.1.3 Manual Handling ......................................................................................................... 17
2.1.4 Business Setup........................................................................................................... 17
2.1.5 Message Data ............................................................................................................ 18
2.2 MT102 Message ............................................................................................................ 19
2.2.1 Overview .................................................................................................................... 19
2.2.2 Processing.................................................................................................................. 20
2.2.3 Manual Handling ......................................................................................................... 25
2.2.4 Business Setup........................................................................................................... 25
2.2.5 Message Data ............................................................................................................ 27
2.3 MT203 Message ............................................................................................................ 28
2.3.1 Overview .................................................................................................................... 28
2.3.2 Processing.................................................................................................................. 29
2.3.3 Manual Handling ......................................................................................................... 31
2.3.4 Business Setup........................................................................................................... 32
2.3.5 Message Data ............................................................................................................ 32
2.4 MT204 Message ............................................................................................................ 32
2.4.1 Overview .................................................................................................................... 32
2.4.2 Processing.................................................................................................................. 33
2.4.3 Manual Handling ......................................................................................................... 36
2.4.4 Business Setup........................................................................................................... 36
2.4.5 Message Data ............................................................................................................ 36
2.5 MT210 Message ............................................................................................................ 37
2.5.1 Overview .................................................................................................................... 37
2.5.2 Processing.................................................................................................................. 37
2.5.3 Manual Handling ......................................................................................................... 38
2.5.4 Business Setup........................................................................................................... 38
2.5.5 Message Data ............................................................................................................ 50
3 ISO 2022 PROCESSING ...................................................................................................... 52
3.1 camt.054 Message ......................................................................................................... 52
APPENDIX A: GLOSSARY ............................................................................................................. 54
Global PAYplus | Message Types | Business Guide Page 5
1 Introduction
1.1 Overview
This document describes the Global PAYplus (GPP) supported functionality for processing messages
within GPP.
SWIFT: The Society for Worldwide Interbank Financial Telecommunication is a member-owned
cooperative through which the financial world conducts its business operations. More than 10,000
banking organizations, securities institutions and corporate customers in 212 countries exchange
millions of standardized financial messages.
- For a list of message types supported in GPP
- For message types processing, see SWIFT Processing
ISO 20022 Message Standards: ISO20022 is a universal financial industry message scheme.
- For a list of message types supported in GPP, see
Global PAYplus | Message Types | Business Guide Page 6
- ISO 20022 Message Standards.
FED: Fedwire Funds Transfer payments. For a list of message types and processing, see GPP
Business Guide FedWire.
CHIPS: The Clearing House Interbank Payments System (CHIPS) is a United States private
clearing house for large-value transactions. For a list of message types and processing, see GPP
Business Guide CHIPS.
Posting Logic: For information on GPP-supported Accounting models, a description of
configurations, and more details about Posting logic manual handling, see GPP Business Guide
Posting.
1.2 SWIFT Messages
These are the SWIFT messages that are supported by GPP:
Message Type
Message
Sub Type
Description
Reference
SWIFT_103
PLS
Single customer credit transfer
For format and rules refer to
SWIFT Book/Category 1/MT103
SWIFT_103
Single customer credit
transfer. The PLS refer to
payment STP
For format and rules refer to
SWIFT Book/Category 1/MT103
SWIFT_190
Advice of charges
For format and rules refer to
SWIFT Book/Category 1/MT190
SWIFT_191
Request for charges
For format and rules refer to
SWIFT Book/Category 1/MT191
SWIFT_192
Request for cancellation
For format and rules refer to
SWIFT Book/Category 1/MT192
SWIFT_195
Queries
SWIFT_196
Answers
SWIFT_198
550
Proprietary message
SWIFT_198
557
SWIFT_198
SWIFT_199
Free format message
SWIFT_200
Financial institution transfer for
each own account
For format and rules refer to
SWIFT Book/Category 2/MT200
SWIFT_202
COV
202 cover - General Financial
Institution Transfer
For format and rules refer to
SWIFT Book/Category 2/MT202
SWIFT_202
General Financial Institution
Transfer
For format and rules refer to
SWIFT Book/Category 2/MT202
SWIFT_205
Financial institution transfer
execution
For format and rules refer to
SWIFT Book/Category 2/MT205
SWIFT_210
RVR
Notice to receive
Global PAYplus | Message Types | Business Guide Page 7
Message Type
Message
Sub Type
Description
Reference
SWIFT_210
SWIFT_290
Advice of charges
SWIFT_291
Request for payment
cancellation
SWIFT_292
SWIFT_295
SWIFT_296
SWIFT_298
550
SWIFT_298
557
SWIFT_298
SWIFT_298_011
SWIFT_298_012
SWIFT_298_013
RVR
SWIFT_298_013
SWIFT_298_014
SWIFT_299
Free format
SWIFT_400
Advice of payment
For format and rules refer to
SWIFT Book/Category 4/MT400
SWIFT_900
Debit confirmation
SWIFT_910
950
Credit confirmation
SWIFT_910
SWIFT_940
Customer statement message
SWIFT_941
Balance report
SWIFT_942
Interim transaction report
SWIFT_950
Statement message
Global PAYplus | Message Types | Business Guide Page 8
1.3 ISO 20022 Message Standards
These are the ISO20022 messages that are supported by GPP.
Message Type
ISO MT Version
Description
ACMT_023
acmt.023.001.01
Account management
CAMT_052
camt.052.001.02
Bank to customer account report
CAMT_053
camt.053.001.02
Bank to customer statement
CAMT_054
camt.054.001.02
camt.054.001.03
camt.054.001.04
Bank to customer debit credit notification
CAMT_029
camt.029.001.03
Resolution of investigation
CAMT_056
camt.056.001.01
FI (financial institution) to FI payment cancellation request
PACS_002
pacs.002.001.03
FI to FI payment status report
PACS_003
pacs.003.001.02
FI to FI customer direct debit
PACS_004
pacs.004.001.02
pacs.004.001.03
Payment return
PACS_007
pacs.007.001.02
FI to FI payment reversal
PACS_008
pacs.008.001.02
FI to FI customer credit transfer
PACS_009
pacs.009.001.02
pacs.009.001.03
PAIN_001
pain.001.001.02
pain.001.001.03
Customer credit transfer initiation
PAIN_002
pain.002.001.02
pain.002.001.03
Customer payment status report
PAIN_007
pain.007.001.02
Customer payment reversal
PAIN_008
pain.008.001.02
Customer direct debit initiation
1.4 Target Audience
This business guide is designed for business analysts and system administrators who need to set up
and configure the Message Types feature. It is also of value to anyone who wants to know more
about how this feature is implemented. This document assumes that the reader is familiar with basic
GPP and financial technology terms and definitions.
2 SWIFT Processing
2.1 MT101 Message
This section describes the processing of MT101 messages received from SWIFT in GPP. The MT101
messages received from SWIFT are de-bulked into individual MT103 child messages. These child
messages either end in GPP as BOOK transfers or are processed via RTGS/SWIFT MOPS as
required.
Global PAYplus | Message Types | Business Guide Page 9
Note: The MT101 message type does not require prior Message User Group (MUG) registration. A
Message User Group (MUG) is a group of users who have voluntarily agreed to support the specified
message type and have registered with SWIFT to send or receive the specified message type. For
more information, see SWIFT Message Types in the SWIFT User Handbook.
2.1.1 Overview
An MT101 SWIFT message is sent by a financial institution on behalf of a non-financial institution
account owner (the ordering customer or instructing party). It is subsequently received by the
receiving financial institution and processed by the receiving financial institution or the account
servicing the financial institution.
The MT101 is used to move funds from the ordering customer's account(s) which are serviced:
At the receiving financial institution
At the account servicing institution
From an account(s) owned by the ordering customer for which the instructing customer has
explicit authority to debit, such as a subsidiary account
MT101 messages can be processed as Incoming SWIFT messages, ending on the bank’s books
only. The child messages can either be settled on the bank’s books or sent out through standard,
applicable MOPs.
2.1.1.1 MT101 Terminology
This is a list of the terms and abbreviations used in this document. Refer to Appendix A: Glossary
Error! Reference source not found.for additional terms and their definitions:
Term
Description
Incoming
MT101 messages received from another financial institution, where the debit
customer’s account (Field 50H) and the credit account (Field 59) are held on the
Local Office’s books.
The child messages are terminated as BOOK payments.
Onward
MT101 messages received from another financial institution, where the debit
customer (Field 50H) holds an account with the Local Office and the credit party
(Field 59) holds an account at another FI (Field 57).
The child messages are sent out to the next FI in the Credit Chain.
Parent message
The Bulked message MT101.
Child message
The de-bulked individual payment message of MT101 (each child of an MT101
is a single MT103)
2.1.1.2 MT101 Sequences
The MT101 consists of these sequences:
Sequence
Name
Description
A
General Description
A single occurrence sequence which contains
information that applies to all individual transactions as
described in Sequence B.
B
Transaction Details
A repetitive sequence in which each occurrence
provides details of one individual transaction.
Fields which appear in both sequences are mutually
exclusive.
Global PAYplus | Message Types | Business Guide Page 10
2.1.2 Processing
2.1.2.1 Incoming MT101 Process
The process flow for incoming MT101 messages is as follows:
1. GPP receives an incoming MT101 from another FI.
- GPP stores the MT101 message in the MINF table in the database with basic level mapping.
For a list of fields, see The incoming MT101 is stored in a new PDO with limited mapping
before spawning the MT103 messages based on Sequence B.
- GPP populates Field 21F (if exists) of the MT101 into the Xchgrate ctrct field and
subsequently copies it into the Contract field of the MESSAGERATES table.
- When an MT101 is received, these fields are mapped in GPP:
No
SWIFT Tag &
Field Name
Field Logical ID
Alias
GPP DB
Table
Comments
1.
NA
P_MID
MID
MINF
System generated
2.
NA
XML_ORIG_MSG
NA
MINF
3.
NA
P_OFFICE
Pmt office
MINF
4.
NA
P_DEPARTMENT
Department
MINF
Set using
Business rule
5.
NA
P_MSG_TYPE
Msg tp
MINF
SWIFT_101
6.
NA
P_MSG_STS
Msg sts
MINF
7.
NA
P_BA_CD
Business area
cd
MINF
Set using
Business rule
8.
NA
P_PRODUCT_CD
Product cd
MINF
Set using
Business rule
9.
NA
P_MSG_CLASS
Msg class
MINF
NAC
10.
NA
P_ORIG_MSG_TYP
E
Orgnl msg tp
MINF
SWIFT_101
11.
NA
P_DISPLAY_MSG_T
YPE
Display Msg tp
MINF
101
12.
NA
P_DBT_MOP
Dbt MOP
MINF
SWIFT
13.
Tag
20:Sender’s
Reference
P_INSTR_ID
Instr ID
MINF
14.
Tag
20:Sender’s
Reference
P_ORIG_INSTR_ID
Original Instr
ID
MINF
15.
Orig Sender
BIC in Block
2
OX_INSTG_AGT_BI
C_2AND
Orgnl Instg agt
BIC 2
XML_OR
IG_MSG
Global PAYplus | Message Types | Business Guide Page 11
No
SWIFT Tag &
Field Name
Field Logical ID
Alias
GPP DB
Table
Comments
16.
Orig Receiver
BIC in Block
1
OX_INSTD_AGT_BI
C_2AND
Orgnl instd agt
BIC 2
XML_OR
IG_MSG
2.1.2.2 Mapping Incoming MT101 to Child MT103
Notes: According to the SWIFT book, Fields 20, 21R, 28D, 51A, 25, 21F and 25A should not be
mapped onto the MT103. However, since Field 20 is mandatory in MT103 and also mandatory for
GPP processing, it is mapped in GPP.
This table shows the mapping of the Original Incoming messages to the applicable child MT103
messages.
Original Incoming MT101 Message
20
21R
28D
50a (C or L)
50a (F, G, or H) - Either in Sequence A or Sequence B
52a (A or C)
51A
30
25
21
21F
23E
32B
56a (A, C, or D)
57a (A, C, or D)
59a (No letter option or A)
70
77B
33B
71A
25A
Global PAYplus | Message Types | Business Guide Page 12
Original Incoming MT101 Message
36
Child MT103
Not mapped onto MT103
Not mapped onto MT103
Not mapped onto MT103
If both Field 50a Instructing Party (50C or L) and Field 50a Ordering
Customer (50F, G or H) are present in the MT101 then, per default,
Field 50a Ordering Customer is mapped onto the subsequent
MT103.
50a (A, F or K)
52a
Not mapped onto MT103
32A (subfield 1)
Note: Field 30 of the MT101 is used to construct subfield 1 of Field
32A of the MT103.
N/A
20
Note: according to SWIFT book It is not mandatory to map Field 21
of the MT 101 in the MT103. However, if required, it should be
mapped onto Field 70 of the MT103 as follows: :70:/ROC/value
Stored in Orgnl xchgrate ctrct field. For more information, see
Mapping of Field 21F of MT101.
23E
32A
Receiver
57a (A, C, or D)
59a (No letter option or A)
70
77B
33B
When present, Field 33B of the MT101 is mapped onto Field 33B
of the MT103.
If Field 33B is not present in the MT101, Field 32B of the MT101
is mapped onto Field 33B of the MT103.
Global PAYplus | Message Types | Business Guide Page 13
Child MT103
In all other cases, Field 32B of the MT101 is used to build
subfields 2 and 3 of Field 32A of the MT103 (see Field 32B).
71A
Stored in the OX_FEE_ACCT_NB/X_FEE_ACCT_NB. For more
information, see Mapping of Field 25 of MT101.
36
- The MT101 message can be viewed in the Before/After tab of the MT101 message. For each
payment, GPP displays in the Before tab the new 101/103 message sub type and in the After
tab the MT103 child).
2. GPP generates the MID for the MT101, which is then is parsed and mapped into the database.
3. GPP invokes the enrichment, product and department rules on MT101.
4. GPP performs a duplication check on the MT101 message.
5. GPP invokes the Set Basic properties service on the MT101, which sets the MID, Dbt MOP and
Pmt Office for the message. Subsequently, rules are invoked to evaluate the Payment attributes -
Department, Business Area and the Product code for the MT101 message.
- If GPP fails to derive these attributes:
› The message is routed to the Repair queue with a relevant error code.
› The message class of the MT101 is set as NAC (non-accounting message class, such as
that used for non-debit lump sum mode).
- If successful, GPP continues to process the message.
6. GPP generates the Local Reference for MT101.
7. GPP de-bulks the MT101 message, spawns the child MT103 messages and moves the MT101 to
the Complete queue. The child MT103 messages are linked to the Orig MT101 in MFAMILY. A
user can view the message from the Links tab in the GPP user interface. For more information,
see De-bulking MT101 to MT103s.
8. GPP then starts processing the individual MT103 child messages.
9. During debit side processing, GPP checks whether the sender’s BIC has debit authority for the
account specified in Field 50H.
- When a Debit Authorization profile does not exist, a relevant error message is recorded and
the MT103 is routed to Repair queue.
- If an F50H account is identified as an invalid account in GPP, MT101 processes STP to
Complete queue, while child MT103s are routed to Repair queue.
10. The individual MT103 message continues to process per standard high value processing of
MT103 messages (for example, Cr side identification, MOP selection/validation, balance checks,
fees, accounting).
2.1.2.3 De-bulking MT101 to MT103s
Once the MT101 is stored in MINF and the basic processing of the message is completed, GPP
spawns multiple MT103 messages (child messages based on Sequence A and B) from the MT101
(parent message) and sends the parent message to Complete.
The message class of the MT101 parent message is set as NAC. The Orig message type (Logical
field P_ORIG_MSG_TYPE) for the MT103 is set as SWIFT_101. The parent MT101 and child
MT103s are linked in MFAMILY.
Global PAYplus | Message Types | Business Guide Page 14
2.1.2.4 De-bulking Parent Messages
The child messages (single instance of a MT101) are assigned with a new message sub type 103 in
SWIFT Tag 119 of the Block 3. The message type remain MT101. GPP generates the child message
as follows:
Original message of the child is inherited from the MT101, containing the entire Sequence A and
the entire respective Sequence B (copy as is).
GPP sends the message back into the queue for processing.
For each payment GPP displays in the Before tab the respective new MT101/MT103 message
type and in the After tab the MT103 child.
GPP generates the MT103 child message as follows:
Outgoing Message of the child (MT103) is formatted as per standard SWIFT guidelines.
The MT101 and the child MT103 remain linked.
MT103 is processed as in the standard high value process.
For mapping details, see Mapping Incoming MT101 to Child MT103.
2.1.2.5 Mapping
The MT101 mapping process has two different goals:
- De-bulking the messages to separate messages
- Mapping the fields from SWIFT format to GPP format
For each MT101, GPP creates one bulked message record in MINF database table, and the
same number of un-bulked message records, as of Sequence B repetitions.
Sequences A and B are mapped to every child message. It is not necessary to have bulk
payments for MT101. That means that an MT101 can have single or multiple occurrences of
payment instructions. Multiple payment instruction have multiple occurrence of Sequence B while
single payment instruction has just one occurrence of Sequence B.
2.1.2.6 Mapping Incoming MT101 to GPP DB
The incoming MT101 is stored in a new PDO with limited mapping before spawning the MT103
messages based on Sequence B.
GPP populates Field 21F (if exists) of the MT101 into the Xchgrate ctrct field and subsequently copies
it into the Contract field of the MESSAGERATES table.
When an MT101 is received, these fields are mapped in GPP:
No
SWIFT Tag &
Field Name
Field Logical ID
Alias
GPP DB
Table
Comments
17.
NA
P_MID
MID
MINF
System generated
18.
NA
XML_ORIG_MSG
NA
MINF
19.
NA
P_OFFICE
Pmt office
MINF
20.
NA
P_DEPARTMENT
Department
MINF
Set using Business
rule
21.
NA
P_MSG_TYPE
Msg tp
MINF
SWIFT_101
22.
NA
P_MSG_STS
Msg sts
MINF
Global PAYplus | Message Types | Business Guide Page 15
No
SWIFT Tag &
Field Name
Field Logical ID
Alias
GPP DB
Table
Comments
23.
NA
P_BA_CD
Business area
cd
MINF
Set using Business
rule
24.
NA
P_PRODUCT_CD
Product cd
MINF
Set using Business
rule
25.
NA
P_MSG_CLASS
Msg class
MINF
NAC
26.
NA
P_ORIG_MSG_TYPE
Orgnl msg tp
MINF
SWIFT_101
27.
NA
P_DISPLAY_MSG_TYP
E
Display Msg tp
MINF
101
28.
NA
P_DBT_MOP
Dbt MOP
MINF
SWIFT
29.
Tag
20:Sender’s
Reference
P_INSTR_ID
Instr ID
MINF
30.
Tag
20:Sender’s
Reference
P_ORIG_INSTR_ID
Original Instr ID
MINF
31.
Orig Sender
BIC in Block 2
OX_INSTG_AGT_BIC_
2AND
Orgnl Instg agt
BIC 2
XML_ORI
G_MSG
32.
Orig Receiver
BIC in Block 1
OX_INSTD_AGT_BIC_
2AND
Orgnl instd agt
BIC 2
XML_ORI
G_MSG
2.1.2.7 Mapping Incoming MT101 to Child MT103
Notes: According to the SWIFT book, Fields 20, 21R, 28D, 51A, 25, 21F and 25A should not be
mapped onto the MT103. However, since Field 20 is mandatory in MT103 and also mandatory for
GPP processing, it is mapped in GPP.
This table shows the mapping of the Original Incoming messages to the applicable child MT103
messages.
Original Incoming MT101
Message
Child MT103
20
Not mapped onto MT103
21R
Not mapped onto MT103
28D
Not mapped onto MT103
50a (C or L)
If both Field 50a Instructing Party (50C or L) and Field 50a Ordering
Customer (50F, G or H) are present in the MT101 then, per default,
Field 50a Ordering Customer is mapped onto the subsequent
MT103.
50a (F, G, or H) - Either in
Sequence A or Sequence B
50a (A, F or K)
52a (A or C)
52a
51A
Not mapped onto MT103
Global PAYplus | Message Types | Business Guide Page 16
Original Incoming MT101
Message
Child MT103
30
32A (subfield 1)
Note: Field 30 of the MT101 is used to construct subfield 1 of Field
32A of the MT103.
25
N/A
21
20
Note: according to SWIFT book It is not mandatory to map Field 21
of the MT 101 in the MT103. However, if required, it should be
mapped onto Field 70 of the MT103 as follows: :70:/ROC/value
21F
Stored in Orgnl xchgrate ctrct field. For more information, see
Mapping of Field 21F of MT101.
23E
23E
32B
32A
56a (A, C, or D)
Receiver
57a (A, C, or D)
57a (A, C, or D)
59a (No letter option or A)
59a (No letter option or A)
70
70
77B
77B
33B
33B
When present, Field 33B of the MT101 is mapped onto Field 33B
of the MT103.
If Field 33B is not present in the MT101, Field 32B of the MT101
is mapped onto Field 33B of the MT103.
In all other cases, Field 32B of the MT101 is used to build
subfields 2 and 3 of Field 32A of the MT103 (see Field 32B).
71A
71A
25A
Stored in the OX_FEE_ACCT_NB/X_FEE_ACCT_NB. For more
information, see Mapping of Field 25 of MT101.
36
36
2.1.2.8 Mapping of Field 21F of MT101
When an MT101 is received, it is de-bulked into individual MT103 messages based on Sequence A
and B. Field 21F of Sequence B of each MT101 is stored in Xchgrate ctrct field (Logical field-
X_XCHGRATEINF_CTRCTID) for each newly spawned MT103. This enables GPP to provide the FX
contract information to the Financial Institution FX engine for validation at the time of FX processing.
A new entry is added to MESSAGERATES table with all mandatory data derived from the payment.
The value in Xchgrate ctrct field is then copied into the Contract field of the MESSAGERATES table in
the database.
Global PAYplus | Message Types | Business Guide Page 17
2.1.2.9 Mapping of Field 25 of MT101
When an MT101 is received with Field 25 quoting fee account number, it is copied to logical fields
OX_FEE_ACCT_NB and X_FEE_ACCT_NB.
The Repair & Enrichment system rule is added to the map fee account as provided in the MT101 to
the processing fee account number P_DBT_FEE_ACCT_NB.
The expectation is that the P_DBT_FEE_ACCT_NB is sent to the external Financial Institution’s
system in the Account lookup request call and the account’s supplementary information is returned as
part of the account lookup response as account number, currency, office to uniquely identify the
relevant fee account as defined in GPP.
The Account lookup response handler uses this information to load the details of the relevant fee
account by the provided account number, currency, and office key. From this point, GPP uses this fee
account for further payment processing, with the assumption is that the fee account is defined in the
GPP.
2.1.3 Manual Handling
2.1.3.1 View Messages
A GPP user can view the following messages in the Message page:
Linked messages: From Links tab of the MT101, the user can view the MT103 message, from any
GPP status. Similarly, the user can also view the MT101 message from the Links tab of the
MT103.
Orig MT101 message: Available from Before/After tab
2.1.3.2 Message Actions
Note: When a button is marked as Button Dual Control Required, it is also required to define the Dual
Control (159) and Message workflow determination – Manual (125) rules, which causes it to be
moved to another approval status.
These buttons (from the MESSAGEBUTTONS table) are available in the MT101 when the status is
Complete.
Queue
Message Button Name
Action
Complete
Save
Save the message
Print
Print the message
Exit
Exit from Message page
Queries
Generate 195
Free Format
Generate any other Free format message
Next
View the next message
2.1.4 Business Setup
There are no system parameters, or business profiles specific to MT101 processing.
2.1.4.1 Business Rules
2.1.4.1.1 Repair and Enrichment Selection Rule (Rule Type ID 145)
Repair and enrichment rules must be defined to set Instruction ID/end-to-end ID for payments created
from templates, in order to avoid duplication.
Global PAYplus | Message Types | Business Guide Page 18
Rule
Name
Rule
Sub
Type
Description
Attached
to
And
/Or
Field/F
ield
Operator
Value
Action
MAP_F
EE_AC
CT
None
Set debit fee
account on
MT103,
generated from
MT101 with
F25
Local office
[Msg
tp]
=
SWIFT_
103
MAP_FEE_
ACCT
And
[Orgnl
msg tp]
=
SWIFT_
101
And
[Orgnl
fee
acct]
Is not
Empty
2.1.4.1.2 Data Manipulation Rule (Rule Type ID 146)
This rule sets the MT103 debit fee. Since debit fees can be defined on the parent message, use of
field tag 71G is also covered as part of GPP’s fee processing module, which processes instruction
currency, message type, MOP (method of payment), and sending and receiving bank message
attributes.
Rule Name
Rule
Sub
Type
Description
Field/Field
Operator
Value
MAP_FEE_
ACCT
Set debit fee
account on
MT103,
generated from
MT101 with
Field 25
[Dbt fee acct nb]
setVal
[Orgnl fee
acct]
2.1.5 Message Data
2.1.5.1 Message Attributes
MT101 message type entry in MSG_TYPES table
MT101 entry in MSG_TYPE_MOP table for SWIFT MOP
Relation type in RELATIONTYPES table links the MT101 message with the de-bulked MT103
messages
2.1.5.2 Errors & Audit Trail
There are no Errors and Audit Trail Messages specific to MT101 processing.
Global PAYplus | Message Types | Business Guide Page 19
2.2 MT102 Message
This section describes the processing of MT102 Multiple Customer Credit Transfer and MT102 STP
(Straight-Through Processing) Multiple Customer Credit Transfer in GPP.
2.2.1 Overview
This table shows the shared similarities and differences between MT102 and MT102 STP.
Message Type Processing
MT102
MT102 STP
Similarities
Sent by, or on behalf of, the FI (Sender) of the ordering customer(s) to
another FI (Receiver) to credit a beneficiary customer directly or
indirectly through a clearing mechanism or another FI, or to issue an
amount to the beneficiary.
Conveys multiple payment instructions between FIs
Bilateral/multi-agreements between Sender and Receiver Agreements
cover transaction amount limits, the currencies accepted, and their
settlement, and can change depending on FI, country, and other
factors.
Requires Prior Message User Group (MUG) registration. A MUG is a
group of users who voluntarily agree to support the specified message
type and are registered with SWIFT to send or receive the specified
message type. For more information, see SWIFT Message Types in the
SWIFT User Handbook.
Maximum message input length 10,000 characters
Differences
Uses a restricted set of MT102 fields and format options to enable the
exchange of multiple customer credit transfers.
This table provides differences between the message types, and additional behavior for MT102 STP.
MT102 Field
MT102 STP Field Option
Field 119
To trigger the MT102 STP format validation, the user header of the message
(block 3) is mandatory and must contain the code STP in the Validation Flag Field
119 ({3:{119:STP}}).
Fields 52, 57
Can be used with the letter option A.
Field 59
Subfield 1 (Account) of Field 59a is mandatory
Field 51A
Not used in MT102 STP. For MT102, this message may only be used on the FIN
SWIFT network since it requires special validation.
Field 72
Code INS must be followed by a valid financial institution BIC.
Codes Reject (REJT) and Return (RETN) must not be used and must not include
ERI information.
Global PAYplus | Message Types | Business Guide Page 20
MT102 Field
MT102 STP Field Option
Field 23
Can contain codes CREDIT and SPAY.
2.2.1.1 MT102 Terminology
This is a list of the terms and abbreviations used in this section.
Term
Description
Parent message
Bulked message MT102 or MT102 STP.
Child message
De-bulked individual payment message of MT102 or MT102 STP. Each child is
handled as a single MT103 or MT103 STP respectively.
2.2.1.2 MT102 Sequences
Both MT102 and MT102 STP consist of these sequences:
Sequence
Name
Description
A
General Information
A single occurrence sequence which contains information that
applies to all individual transactions in Sequence B.
B
Transaction Details
A repetitive sequence in which each occurrence provides details
of a single individual transaction. Fields which appear in both
Sequences (A and B) are mutually exclusive.
C
Settlement Details
A single occurrence sequence that contains information about
the settlement.
For more information about mapping sequences to child messages, see Mapping.
2.2.2 Processing
GPP does not perform SWIFT validations on incoming payments, incoming bulk MT102 or MT102
STP messages.
2.2.2.1 Incoming MT102 Process
GPP uses these internal message types to process MT102 and MT102 STP incoming bulk
messages:
SWIFT_102
SWIFT_102 PLS
Note: When a message subtype field is set to PLS, GPP formats the message in such a way that the
message processes straight through (STP), with no errors.
Bulk messages are defined with internal GPP message types and relevant business definitions:
Message Type
Message Sub Type
Description
SWIFT_102
N/A
MT102 Multiple Customer Credit Transfer
SWIFT_102
PLS
MT102 STP Multiple Customer Credit Transfer
Global PAYplus | Message Types | Business Guide Page 21
These message types identify inbound messages by parsing and storing them in the GPP DB. Once
identified, the messages are processed.
GPP supports these modes for processing bulk messages:
Debit lump sum mode (with debit lump sum). From the Processing tab in the Parties profile, the
Debit Lump Sum checkbox, if selected, maintains debit lump sum indication.
Non-debit lump sum mode (without debit lump sum)
The mode is determined during the debit side derivation and funds authorization step, and is based
on the business setup at a customer level:
If the setup instructs to perform debit lump sum on bulk messages, bulk messages undergo all
further payment steps of the process. The debit leg of the posting is submitted as a single debit
entry. Inbound bulk messages are parsed and stored in the GPP database.
If no debit lump sum is required, bulk messages are sent directly to completion. Both debit and
credit posting legs are performed on individuals.
Note: As part of the Termination process, only successfully processed bulk messages continue to
the process of de-bulking and mapping into individuals.
When defining fee-related rules, these guidelines need to be considered:
Debit lump sum mode: If a bulk message is an accounting message (indicated by the message
class PAY), the debit side fees (where applicable) are set on the original parent message and the
credit side fees (when relevant), are set on child individual payments.
Note: GPP cancellation flow can reverse the respective individual account, which was already
taken on the parent on the individual payment, if the linked parent’s message class is PAY.
Non-debit lump sum mode: All fees (when relevant) are set on child individual payments. Fees
are handled as per GPP core processing; this includes handling of fees as it is specified in Fields
71A and 71G if present.
2.2.2.2 De-bulking Parent Messages
Inbound bulk messages are parsed and stored in GPP-SP DB. Bulk parent messages are de-bulked
and mapped into child messages, and linked via MFAMILY. Child messages are mapped with
information from the parent and are processed individually. To view details about parent/child linkage
(MFAMILY), the user can click Links from the GPP Message page.
How the parent message is processed determines the mode used to process the child message:
In Debit lump sum mode, the debit leg previously done on the parent message performs the
posting
In Non-debit lump sum mode, the child message performs the posting
2.2.2.3 Mapping
GPP creates one parent, and multiple child messages:
The parent message includes Sequences A, B, and relevant sections from Sequence C
The child message includes Sequence A, relevant sections from Sequence Bn, and relevant
fields from Sequence C
2.2.2.3.1 Bulk and Individual Message Types and Mapping
This table shows the SWIFT and internal GPP message type definitions and mapping of bulk
information into individuals. For more information about sequences, see MT102 Sequences.
Global PAYplus | Message Types | Business Guide Page 22
MT102 Multiple
Customer
Credit Transfer
MT103 Single
Customer Credit
Transfer
MT102 STP
Multiple Customer
Credit Transfer
MT103 STP Single
Customer Credit
Transfer
SWIFT
Message Type
MT102
MT103
MT102 STP
MT103 STP
GPP Message
Type
SWIFT_102
SWIFT_103
SWIFT_102, Sub
Type PLS
SWIFT_103, Sub
Type PLS
Sequence A
Sequence A
Sequence A
Sequence A
Sequence A
Sequence B
Sequence B1
…
Sequence Bn
Sequence Bm
Sequence B1
…
Sequence Bn
Sequence Bm
Sequence C
Sequence C
Sequence C
Sequence C
Sequence C
2.2.2.3.2 MT102 Multiple Customer Credit Transfer
When an MT102 is received, these fields are mapped in GPP.
No
Status
SWIFT Tag &
Field Name
Field Logical ID
Content/Options
General Information
1.
Mandatory
20
File Reference
16x
2.
Mandatory
23
Bank Operation Code
16x
3.
Optional
51A
Sending Institution
[/1!a][/34x]
4!a2!a2!c[3!c]
4.
Optional
50a
Ordering Customer
A, F, or K
5.
Optional
52a
Ordering Institution
A, B, or C
6.
Optional
26T
Transaction Type Code
3!c
Optional
77B
Regulatory Reporting
3*35x
7.
Optional
71A
Details of Charges
3!a
8.
Optional
36
Exchange Rate
12d
Transaction Details (Repetitive)
9.
Mandatory
21
Transaction Reference
16x
10.
Mandatory
32B
Transaction Amount
3!a15d
11.
Optional
50a
Ordering Customer
A, F, or K
12.
Optional
52a
Ordering Institution
A, B, or C
13.
Optional
57a
Account With Institution
A or C
14.
Mandatory
59a
Beneficiary Customer
No letter option, A, or F
15.
Optional
70
Remittance Information
4*35x
Global PAYplus | Message Types | Business Guide Page 23
No
Status
SWIFT Tag &
Field Name
Field Logical ID
Content/Options
16.
Optional
26T
Transaction Type Code
3!c
17.
Optional
77B
Regulatory Reporting
3*35x
18.
Optional
33B
Currency/Instructed Amount
3!a15d
19.
Optional
71A
Details of Charges
3!a
20.
71F
Sender's Charges
3!a15d
21.
Optional
71G
Receiver's Charges
3!a15d
22.
Optional
36
Exchange Rate
12d
Settlement Details
23.
Mandatory
32A
Value Date, Currency Code, Amount
6!n3!a15d
24.
Optional
19
Sum of Amounts
17d
25.
Optional
71G
Sum of Receiver's Charges
3!a15d
26.
Optional
13C
Time Indication
/8c/4!n1!x4!n
27.
Optional
53a
Sender's Correspondent
A or C
28.
Optional
54A
Receiver's Correspondent
[/1!a][/34x]
4!a2!a2!c[3!c]
29.
Optional
72
Sender to Receiver Information
6*35x
2.2.2.3.3 MT102 STP Multiple Customer Credit Transfer
When an MT102 is received, these fields are mapped in GPP.
No
Status
SWIFT Tag & Field
Name
Field Logical ID
Content/Options
General Information
30.
Mandatory
20
File Reference
16x
31.
Mandatory
23
Bank Operation Code
16x
32.
Optional
50a
Ordering Customer
A, F, or K
33.
Optional
52a
Ordering Institution
A, B, or C
34.
Optional
26T
Transaction Type Code
3!c
35.
Optional
77B
Regulatory Reporting
3*35x
36.
Optional
71A
Details of Charges
3!a
37.
Optional
36
Exchange Rate
12d
Transaction Details (Repetitive)
Global PAYplus | Message Types | Business Guide Page 24
No
Status
SWIFT Tag & Field
Name
Field Logical ID
Content/Options
38.
Mandatory
21
Transaction Reference
16x
39.
Mandatory
32B
Transaction Amount
3!a15d
40.
Optional
50a
Ordering Customer
A, F, or K
41.
Optional
52a
Ordering Institution
A, B, or C
42.
Optional
57a
Account With Institution
A or C
43.
Mandatory
59a
Beneficiary Customer
No letter option, A, or F
44.
Optional
70
Remittance Information
4*35x
45.
Optional
26T
Transaction Type Code
3!c
46.
Optional
77B
Regulatory Reporting
3*35x
47.
Optional
33B
Currency/Instructed Amount
3!a15d
48.
Optional
71A
Details of Charges
3!a
49.
71F
Sender's Charges
3!a15d
50.
Optional
71G
Sum of Receiver's Charges
3!a15d
51.
Optional
36
Exchange Rate
12d
Settlement Details
52.
Mandatory
32A
Value Date, Currency Code,
Amount
6!n3!a15d
53.
Optional
19
Sum of Amounts
17d
54.
Optional
71G
Sum of Receiver's Charges
3!a15d
55.
Optional
13C
Time Indication
/8c/4!n1!x4!n
56.
Optional
53a
Sender's Correspondent
A or C
57.
Optional
54A
Receiver's Correspondent
[/1!a][/34x]
4!a2!a2!c[3!c]
58.
Optional
72
Sender to Receiver
Information
6*35x
2.2.2.4 Fees
The following indicators may be used when defining user-defined business rules, for example, fee-
related rules:
Message
Indication
De-bulked Message
Indicates if a message is a result of the de-bulking process, for example,
an MT103 individual payment as a result of the MT102 bulked message
de-bulking process.
Global PAYplus | Message Types | Business Guide Page 25
Message
Indication
Bulk Message
Indicates if this is a bulk message, containing information of multiple
individual messages, for example, MT103 as a bulk message that
contains information regarding individual MT103 payments.
Bulk Message Class
Indicates the message class of a bulk message, for example, PAY for
Debit lump sum mode, or NAC for non-accounting debit lump sum mode.
2.2.2.5 Posting
Generation of accounting entries are performed as per standard posting models. Customer specific
configuration is covered by customization of posting solutions.
The decision on whether bulk message is an accounting or a non-accounting message is done during
the Debit side derivation process as part of the Payment classification step:
The parent bulk message is considered as an accounting PAY message when the Debit lump
sum field on the Parties profile is selected for a debit party, and associated with the processed
payment. The bulk message continues with the High-value-like flow.
When the Debit lump sum field on the Parties profile is not selected, the bulk message is
classified as a non-accounting NAC message and proceeds to the Termination flow for
completion and de-bulking. No accounting is done on the parent message – posting is done on
individual payments only. The credit MOP is automatically set to BOOK.
2.2.3 Manual Handling
2.2.3.1 View Messages
A GPP user can view and monitor bulk message details of the MT102 in the Message page. The
Message page for individual MT103s provides information of specific bulk messages.
The Properties tab of the Message page includes bulk-related information regarding the sum of
amounts of individual messages.
GPP prevents cancellation of completed bulk messages by disabling the Cancel button when
MT102 and MT102 STP are in Complete status.
2.2.3.2 Message Actions
MT102 has no message actions.
2.2.4 Business Setup
There are no system parameters, or business profiles specific to MT102 processing.
2.2.4.1 Business Rules
2.2.4.1.1 MOP (Method of Payment) Selection Rule (Rule Type ID 3)
This rule, which applies to both MT102 and MT102 STP (with message sub type PLS), is used to
determine and assign the method to be used to send the message.
Note: When a message subtype field is set to PLS, GPP formats the message in such a way that the
message processes straight through (STP), with no errors.
Rule
Name
Rule
Sub
Type
Description
Attached
to
AND/
OR
Field/
Field
Operator
Value/
Field/
Function
Action
INC_B
ULK_M
N/A
Select Credit
MOP=BOOK
Local office
[Msg tp]
=
SWIFT_10
2
BOOK
Global PAYplus | Message Types | Business Guide Page 26
Rule
Name
Rule
Sub
Type
Description
Attached
to
AND/
OR
Field/
Field
Operator
Value/
Field/
Function
Action
SG_10
2
for incoming
bulk
messages 102
and 102 STP;
should not
exceed 1000
characters
2.2.4.1.2 Credit Party Chain Enrichment (Rule Type ID 168)
This rule is applicable for both MT102 and MT102 STP. GPP uses this rule to select a local office’s
party for bulk MT102 and MT102 STP if processed as PAY (an accounting message, such as that
used for debit lump sum mode.) Customer business requirements determine this rule’s setup.
Rule
Name
Rule
Sub
Type
Description
Attached
to
AND/
OR
Field/
Field
Operator
Value/
Field/
Function
Action
INC_B
ULK_M
SG_10
2
N/A
Select Local
Office’s party
for bulk
MT102 and
MT102 STP if
processed as
PAY
Local office
[Msg tp]
=
SWIFT_10
2
<Local
Office’s
Party>
Usage:
Replace
First
[Msg
class]
=
PAY
2.2.4.1.3 Credit Account Enrichment (Rule Type ID 170)
This rule is applicable for both MT102 and MT102 STP. GPP uses this rule to select a credit
suspense account for a single debit posting.
Rule
Name
Rule
Sub
Type
Description
Attached
to
AND/
OR
Field/
Field
Operator
Value/
Field/
Function
Action
INC_B
ULK_M
SG_10
2
N/A
Select credit
suspense
account for
the single
debit posting
for MT102 and
MT102 STP
Local office
[Msg tp]
=
SWIFT_10
2
<Office^
Credit
Suspens
e
account^
Currency
>
Usage:
Override
account
[Msg
class]
=
PAY
2.2.4.1.4 BI-Bypass Business Rule (Rule Type ID 47)
This rule, available in the GPP user interface, is applied if it is required to skip debit account balance
check on bulk messages. The actual setup is defined as per specific customer business
requirements. This rule is applicable for both MT102 and MT102 STP.
Global PAYplus | Message Types | Business Guide Page 27
Note: Criteria is controlled by the Interface Selection Rule (Rule Type ID 189) and is covered as part
of the customization Balance inquiry solution.
Rule
Name
Rule
Sub
Type
Description
Attached
to
AND/
OR
Field/
Field
Operator
Value/
Field/
Function
Action
INC_B
ULK_M
SG_10
2
N/A
BI-bypass for
bulk
messages
MT102 and
MT102 STP,
which are
processed in
GPP as PAY
messages
Local office
[Msg tp]
=
SWIFT_10
2
BYPASS
[Msg
class]
=
PAY
2.2.5 Message Data
2.2.5.1 Message Attributes
There are no Message Attributes specific to MT102 processing.
2.2.5.2 Errors & Audit Trail
There are no Errors and Audit Trail messages specific to MT102 processing.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 28
2.3 MT203 Message
This section describes the processing of MT203 messages received from SWIFT in GPP. The MT203
multi-message is sent by, or on behalf of, the ordering FI directly, or through correspondence, to the
FIs of one or more beneficiary institution(s).
Note: The MT203 message type does not require prior Message User Group (MUG) registration.
2.3.1 Overview
The MT203 multi-message is used to order the movement of specific funds to each beneficiary
institution. GPP parses and processes inbound MT203 messages and stores it in the GPP database.
The message may contain order(s) for the movement of the Sender's own funds in favor of itself, for
instance, when the Receiver services multiple accounts for the Sender and the funds are to be
transferred between these accounts.
MT203 can be sent to an FI to debit an account of the Sender serviced by the Receiver, and Credit an
account owned by the Sender at an FI as specified in Field 57a. Each incoming MT203 is parsed and
de-bulked into child MT202s. For information about MT203 attributes.
2.3.1.1 MT203 Terminology
This is a list of the terms and abbreviations used in this section.
Term
Description
Incoming
MT203 containing two or more transactions received by an ordering FI.
Onward
MT203 messages received from an FI that contains orders for transfer of funds
to one or more beneficiary FIs.
Parent message
The Bulked message MT203.
Child message
The de-bulked individual payment message of MT203. A child MT202 has the
original message type of SWIFT_203.
2.3.1.2 MT203 Sequences
The MT203 consists of these sequences types:
Sequence
Name
Description
A
General Description
Provides details of the transaction between the Sender and
Receiver, that is, the value date and total amount to be
transferred, as well as any other information about this
transaction, as necessary.
B
Transaction Details
Provides details of the transaction between the Receiver and
the FI to which the funds will be transferred, and includes:
The reference of the related transaction (TRN)
The amount and currency code to be transferred
The identification of the beneficiary institution and any other
institution(s) through which the funds will pass
Any other information about the transaction, as necessary
Note: Sequence B must appear at least twice and, in order to
expedite processing, not more than ten times.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 29
2.3.2 Processing
GPP supports parsing and processing of inbound MT203 messages.
2.3.2.1 Incoming MT203 Process
GPP processes the MT203 as follows:
Parses and stores the MT203 in the GPP database. The MT203 is can be viewed in the GPP user
interface, Message page
This table provides information about the formats used with MT203.
No
Status
SWIFT Tag &
Field Name
Field Logical ID
Content/Options
1.
Mandatory
19
Sum of Amounts
17d
2.
Mandatory
30
Value Date
6!m
3.
Optional
52a
Ordering Institution
A or D
4.
Optional
53a
Sender’s Correspondent
A, B, or D
5.
Optional
54a
Receiver’s Correspondent
A, B, or D
6.
Optional
72
Sender to Receiver Information
6*35x
7.
Mandatory
20
Transaction Reference Number
16x
8.
Mandatory
21
Related Reference
16x
9.
Mandatory
32B
Currency Code, Amount
3!a15d
10.
Optional
56a
Intermediary
A or D
11.
Optional
57a
Account With Institution
A, B, or D
12.
Mandatory
58a
Beneficiary Institution
A or D
13.
Optional
72
Sender to Receiver Information
6*35x
Manual Handling
Maps the payment information, such as MID, Office, Department, Product Code
Sets the Message Class to NAC (non-accounting message class
De-bulks the MT203 into child MT202s
Links the MT203 to child MT202s via MFAMILY in the ‘Bulk^Child’ relation type. For more
information see MT203 De-bulking
Completes the process
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 30
2.3.2.2 MT203 De-bulking to MT202
Incoming MT203 messages are parsed and de-bulked into child MT202s as follows:
Each child MT202 carries the original message type of the MT203. The child MT202 Original XML
include MT203 Sequence A + respective Sequence B.
The child MT202 is mapped with information from the parent MT203 and is processed individually
in GPP.
The child MT202 is processed in GPP in the high value flow, including debit/credit side derivation,
debit authorization, fees, FX, MOP selection, Value date determination, Sanctions, Posting &
Balance. Relevant debit authorization profiles need to be defined to allow the MT203 sender to
debit F53 account according to the FI’s requirements.
The child MT202 derives the debit account from the debit chain (Field 52, Field 53, Field 54) or
the original sender.
The child MT202 credit account is derived from Field 57 and Field 58.
2.3.2.3 MT203 Parsing
This table shows the mapping of the original MT203 and respective logical fields for Sequence A.
Original Incoming MT203
Logical Fields
19
OX_SUM_OF_AMOUNTS/X_SUM_OF_AMOUNTS
30
OX_STTLM_DT_1B/X_STTLM_DT_1B
52a
OX_DBTR_AGT/X_DBTR_AGT
*Including all sub-fields*
53a
OX_INSTG_RMB_AGT/X_INSTG_RMB_AGT
*Including all sub-fields*
54a
OX_INSTD_RMB_AGT/X_INSTD_RMB_AGT
*Including all sub-fields*
72
OX_INSTR_CDTR_AGT/X_INSTR_CDTR_AGT
OX_INSTR_NXT_AGT/X_INSTR_NXT_AGT
OX_INSTR_NXT_AGT_OTHER_CODES/X_INSTR_NXT_AGT_OTH
ER_CODES
OX_PRVS_INSTG_AGT_NM/X_PRVS_INSTG_AGT_NM
*Including all sub-fields*
2.3.2.4 MT202 Mapping
Incoming MT203 is parsed and de-bulked into child MT202s.
GPP creates a child MT202 which will have the original message type of SWIFT_203. Child MT202
Original XML (Before tab) include MT203 General Information and Transaction Details.
The parsed message fields of the MT202 will be as follows:
Field
Mapping
F20
Mapped from MT203 respective Sequence B F20
F21
Mapped from MT203 Sequence B F21
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 31
Field
Mapping
F32 Value Date
Mapped from MT203 Sequence A F30
F32 Currency and Amount
Mapped from MT203 Sequence B F32B
F52
Mapped from MT203 Sequence A F52, if exists
F53
Mapped from MT203 Sequence A F53, if exists
F54
Mapped from MT203 Sequence A F54 (if exists)
F56
Mapped from MT203 Sequence B F56 (if exists)
F57
Mapped from MT203 Sequence B F57 (if exists)
F58
Mapped from MT203 Sequence B F58
F72
F72 will be mapped from MT203 respective Sequence B F72, if
exists; if not, mapped from F72 Sequence A (if exists)
2.3.2.5 MT203 Format
This table provides information about the formats used with MT203.
No
Status
SWIFT Tag & Field
Name
Field Logical ID
Content/Options
1.
Mandatory
19
Sum of Amounts
17d
2.
Mandatory
30
Value Date
6!m
3.
Optional
52a
Ordering Institution
A or D
4.
Optional
53a
Sender’s Correspondent
A, B, or D
5.
Optional
54a
Receiver’s Correspondent
A, B, or D
6.
Optional
72
Sender to Receiver Information
6*35x
----->
7.
Mandatory
20
Transaction Reference
Number
16x
8.
Mandatory
21
Related Reference
16x
9.
Mandatory
32B
Currency Code, Amount
3!a15d
10.
Optional
56a
Intermediary
A or D
11.
Optional
57a
Account With Institution
A, B, or D
12.
Mandatory
58a
Beneficiary Institution
A or D
13.
Optional
72
Sender to Receiver Information
6*35x
-----|
2.3.3 Manual Handling
2.3.3.1 View Messages
A GPP user can view messages from the Message page.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 32
MT203 Message: GPP retains the links between the parent MT203 message and all child MT202
messages. These links can be viewed from the Links tab. Users can navigate from the parent
MT203 to each child MT202 message.
MT202 Message: The Before tab displays the message in original incoming XML format (MT203
Sequence A plus the respective Sequence B) as it was received. GPP retains the links between
the parent MT203 message and all child MT202 messages. These links can be viewed from the
Links tab. Users can navigate from the child MT202 to the parent MT203 message.
2.3.3.2 Message Actions
MT203 has no message actions.
2.3.4 Business Setup
There are no system parameters, business profiles or business rules specific to MT203 processing.
2.3.5 Message Data
2.3.5.1 Message Attributes
The description for this message is MT203 Multiple General Financial Institution Transfer.
This message appears as SWIFT_203 in the MSG_TYPES table.
As defined in MSG_TYPES_MOP, this message appears as:
MSG_TYPE=SWIFT_203
MOP=SWIFT
2.3.5.2 Errors & Audit Trail
There are no Errors and Audit Trail Messages specific to MT203 processing.
2.4 MT204 Message
2.4.1 Overview
The MT204 message is sent from an exchange, clearing house, or another financial institution (FI), to
an FI to instruct the Receiver of the message to debit the account(s) of a third party as specified in the
message, and to pay or credit the corresponding amount in favor of the Sender of the message.
Note: The MT204 message type requires prior Message User Group (MUG) registration. A Message
User Group (MUG) is a group of users who have voluntarily agreed to support the specified message
type and have registered with SWIFT to send or receive the specified message type. For more
information, see Error! Reference source not found..
Each incoming MT204 is parsed and de-bulked into child MT202s. For information about MT204
attributes, see MT204 Format.
2.4.1.1 MT204 Terminology
This is a list of the terms and abbreviations used in this section.
Term
Description
Incoming
MT204 containing two or more transactions received by an ordering FI.
Onward
MT204 messages received from an FI that contains orders for transfer of funds
to one or more beneficiary FIs.
Parent message
The bulked message MT204. .
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 33
Term
Description
Child message
The de-bulked individual payment message of MT204. Each child of an MT204
is a single MT202 message. For more information about parent and child
messages, see MT204 De-bulking.
2.4.1.2 MT204 Sequences
MT204 consists of these sequences:
Sequence
Name
Description
A
Common Elements
Reimbursement details of a single occurrence sequence;
contains default information valid for individual transactions
(described in Sequence B) and the total amount to be
reimbursed.
B
Transaction Details
A repetitive sequence in which each occurrence provides
details for one individual transaction (debit).
An MT204 received from SWIFT with multiple instances of
Sequence B will be de-bulked into individual MT202
messages for processing.
Each child MT202 will have original message type of
SWIFT_204.
Child MT202 Original XML will include MT204 sequence A +
respective Sequence B.
Child MT202 original XML includes MT204 Sequence A and respective Sequence B. From the
Message page, the user can click the Before tab to view the message type’s original XML.
2.4.2 Processing
GPP supports parsing and processing of inbound MT204 messages.
2.4.2.1 Incoming MT204 Process
GPP processes the incoming MT204 as follows:
Parses and stores the MT204 in the GPP database. The MT204 is can be viewed in the GPP user
interface, Message page. For more information, see Manual HandlingError! Reference source n
ot found..
Maps the payment information, for example, MID, Office, Department, and Product Code data
Sets the Message class to NAC (non-accounting message class
GPP-SP de-bulks the parent MT204 into child MT202s, and links the MT204 and child MT202s
via the MFAMILY table in the Bulk^Child relation type. For more information, see MT204 De-
bulking.
2.4.2.2 MT204 De-bulking
GPP de-bulks the parent MT204 into child MT202s. Once de-bulked, the parent MT204 message
status changes to Complete.
Each child MT202 carries the original message type of the MT204. The child MT202 Original XML
include MT203 Sequence A + respective Sequence B.
The child MT202 is mapped with information from the parent MT204 and is processed individually
in GPP.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 34
The child MT202 is processed in GPP in the high value flow, including debit/credit side derivation,
debit authorization, fees, FX, MOP selection, Value date determination, Sanctions, Posting &
Balance.
The child MT202s will derive the debit account from Field 53, quoted in the message. Credit
account will be derived from F57/8 or the original sender.
Since the sender of the MT204 is not the owner of the account in Field 53, debit authorization
check will be done on the child MT202s.
For more information see MT204 Parsing.
For more information about mapping, see MT204 Parsing
This table shows the mapping of the original MT204 and respective logical fields for Sequence A.
Original Incoming MT204
Logical Fields
Sequence A
20
OX_INSTR_ID/X_INSTR_ID
19
OX_SUM_OF_AMOUNTS/X_SUM_OF_AMOUNTS
30
OX_STTLM_DT_1B/X_STTLM_DT_1B
57A
OX_CDTR_AGT/X_CDTR_AGT
*Including all sub-fields*
58A
OX_CDTR/X_CDTR
*Including all sub-fields*
72
OX_INSTR_CDTR_AGT/X_INSTR_CDTR_AGT
OX_INSTR_NXT_AGT/X_INSTR_NXT_AGT
OX_INSTR_NXT_AGT_OTHER_CODES/X_INSTR_NXT_AGT_OTH
ER_CODES
OX_PRVS_INSTG_AGT_NM/X_PRVS_INSTG_AGT_NM
*Including all sub-fields*
This table shows the mapping of the original MT204 and respective logical fields for Sequence A.
Original Incoming MT204
Logical Fields
Sequence A
20
OX_INSTR_ID/X_INSTR_ID
19
OX_SUM_OF_AMOUNTS/X_SUM_OF_AMOUNTS
30
OX_STTLM_DT_1B/X_STTLM_DT_1B
57A
OX_CDTR_AGT/X_CDTR_AGT
*Including all sub-fields*
58A
OX_CDTR/X_CDTR
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 35
Original Incoming MT204
Logical Fields
*Including all sub-fields*
72
OX_INSTR_CDTR_AGT/X_INSTR_CDTR_AGT
OX_INSTR_NXT_AGT/X_INSTR_NXT_AGT
OX_INSTR_NXT_AGT_OTHER_CODES/X_INSTR_NXT_AGT_OTH
ER_CODES
OX_PRVS_INSTG_AGT_NM/X_PRVS_INSTG_AGT_NM
*Including all sub-fields*
2.4.2.3 MT202 Mapping
This table lists the parsed message fields of the MT202.
Field
Mapping
F20
Mapped from MT204 respective Sequence B F20
F21
Mapped from MT204 Sequence B F21
F32 Value Date
Mapped from MT204 Sequence A F30
F32 Currency and Amount
Mapped from MT204 Sequence B F32B
F53
Mapped from MT204 Sequence B F53.
The child MT202s derive the debit account from Field 53, as
quoted in the message.
Since the sender of the MT204 is not the owner of the account in
Field 53, debit authorization check will be done on the child
MT202s.
Child MT202s derive the debit account from Field 53, as identified
in the message.
F57
Mapped from MT204 Sequence A F57, if exists
F58
Mapped from MT204 Sequence A F58, if exists
The credit account is derived from F57 and F58 of the original sender.
If F57 and F58 do not exist in MT204 Sequence A, GPP maps F58
from the MT204 sender’s BIC.
F72
Mapped from MT204 respective Sequence B F72, if exists. If not, map
from F72 Sequence A (if exists).
2.4.2.4 MT204 Format
This table provides information about the formats used with MT204.
No
Status
SWIFT Tag &
Field Name
Field Logical ID
Content/Options
1.
Mandatory
20
2.
Mandatory
19
Sum of Amounts
17d
3.
Mandatory
30
Value Date
6!n
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 36
No
Status
SWIFT Tag &
Field Name
Field Logical ID
Content/Options
4.
Optional
57a
Account With Institution
A, B, or D
5.
Optional
58a
Beneficiary Institution
A or D
6.
Optional
72
Sender to Receiver Information
6*35x
7.
Mandatory
20
Transaction Reference No.
16x
8.
Optional
21
Related Reference
16x
9.
Mandatory
32B
Transaction Amount
3!a15d
10.
Mandatory
53a
Debit Institution
A, B, or D
11.
Optional
72
Sender to Receiver Information
6*35x
2.4.3 Manual Handling
2.4.3.1 View Messages
A GPP user can view messages from the Message page:
MT204 messages: GPP retains the links between the parent MT204 message and all child
MT202 messages. These links can be viewed from the Links tab. Users can navigate from the
parent MT204 to each child MT202 message.
MT202 messages: The Before tab displays the message in original incoming XML format as it
was received. GPP retains the links between the parent MT204 message and all child MT202
messages. These links can be viewed from the Links tab. Users can navigate from the child
MT202 to the parent MT204 message.
2.4.3.2 Message Actions
MT204 has no message actions.
2.4.4 Business Setup
There are no system parameters, or business rules specific to MT204 processing.
2.4.4.1 Profiles
2.4.4.1.1 Debit Authorization Profile
The Debit Authorizations profile validates that senders of funds are authorized to debit an account
that does not belong to them.
The relevant debit authorization profiles need to be defined to allow the MT204 sender to debit F53
account.
2.4.5 Message Data
2.4.5.1 Message Attributes
Within GPP, the MT204 Message description is MT 204 Financial Markets Direct Debit Message.
MT204 message type entry in MSG_TYPES table:
o MSG_TYPE = SWIFT_204
MT204 message type entry in MSG_TYPE_MOP for SWIFT MOP:
o MSG_TYPE = SWIFT_204
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 37
o MOP = SWIFT
2.4.5.2 Errors & Audit Trail
There are no Errors and Audit Trail Messages specific to MT204 processing.MT
2.5 MT210 Message
2.5.1 Overview
MT210 is an advance notice to the account servicing institution that it will receive funds to be credited
to the Sender's account. The Notice to Receive information is contained on one tab: Notice to Receive
Required - for message identification, Credit Account, Ordering Party, Intermediary Bank and Amount.
2.5.2 Processing
GPP processes the message MT210 (notice to receive) for the following business scenarios:
Service to Vostro Customer: Customers/financial institutions can send an MT210 for anticipated
funds which they are expecting to receive in their accounts or one of its account serving
institutions. It is used to track the projected end of day balance. GPP accepts such payments and
supports automatic as well as manual matching with incoming receipt of funds (serial as well as
cover messages). Multiple matching methods can be supported via system configuration. GPP
supports full match as well as possible match. The possible match is to be manually reconciled
and this is facilitated by an easy-to-use split screen user interface.
Internal MT210 against Charges: GPP supports the automatic generation of MT210 messages
when creating an outward MT191 - Request for Charges. These MT210s are used to track the
expected charges.
2.5.2.1 Credit Anticipated Funds
GPP displays the amount of MT210 as credit anticipated funds, meaning funds to be received at the
Nostro account. Once matched with an incoming payment message such MT210s are no longer
considered as credit anticipated funds.
2.5.2.2 Reversed MT210
GPP supports MT210 that are marked as “Reversed.” Such messages indicate anticipated funds to
be withdrawn from a Nostro/Settlement account as a result from the bank’s own activity. Reversed
MT210 can be either received from a feeder system or manually created. Reversed MT210 are
accumulated into the debit anticipated funds figure on the position window as long as such messages
were not yet matched with an actual payment message. Once matched with an outgoing payment
message, reversed MT210 are no longer considered as debit anticipated funds.
2.5.2.3 Earmarking Reversed MT210
GPP enables the user to mark particular reversed MT210. By earmarking, GPP makes it possible to
reserve liquidity with the amount mentioned in the reversed MT210. Once an outgoing payment
message is matched with an “earmarked” MT210, it inherits the “earmark” indication and thus is
entitled for the previously reserved liquidity. The amount of all earmarked MT210 that were not yet
matched with an outgoing payment message impacts both the operating and the high payment
capacities.
This mechanism is particularly used for CLS payments.
2.5.2.4 Automatic 210 Matching
GPP incorporates an automatic matching mechanism between anticipated funds and payment
messages. This automatic mechanism is based on user defined rules. When a payment message or
anticipated funds message are processed, GPP scans the predefined automatic matching rules to
associates between the anticipated funds and the payment message or vice versa. If GPP was
unable to find a unique match it indicates the possible candidates for matching.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 38
2.5.2.5 Manual 210 Matching
In addition to the automatic matching, GPP enables manual reconciliation between a payment
message to anticipated funds message. By highlighting both a specific payment message and a
specific anticipated funds message via the various messages queues, they can link and match both
messages.
2.5.3 Manual Handling
2.5.4 Business Setup
2.5.4.1 210 Matching
2.5.4.1.1 210 Matching – Background Definitions
210 Matching Fields
The following table defines the fields of the payment and MT210 that are used in the MT210 matching
algorithms.
Field Name in
Algorithm
Field in Payment
Field in 210
Currency
Currency in F32A or F72/OCMT/ or
F33B of the message (Mif.orig_currency
or mif.ocmt_currency or
mif.instruct_currency)
Currency in F32B of the message
(Mif.currency)
Reference
If reference in F21 exists then F21 else
reference in F20 of the message
(If Mif.orig_rfb not empty then
Mif.orig_rfb
Else
Mif.orig_reference)
Reference in F21 of the message
(Mtf1000.rfb)
Special
Reference
If Reference in F21 exists then F21
Else reference in F20 of the mesage
(If Mif.orig_rfb not empty then
Mif.orig_rfb
Else
Mif.orig_reference)
Reference in F20 of the message
(Mif.reference)
Amount
Amount in F32A or F72/OCMT/ or F33B
of the message.
(Either Mif.orig_amount or
mif.ocmt_amount or
mif.instruct_amount, depending on the
first currency field that was matched)
Amount in F32B of the message
(Mif.amount)
Value Date
Value Date in F32A of the message
(Mif.orig_value_date)
Value Date in F30 of the message.
(Mif.value_date)
Paying Bank
Sender of the message
(Mif.orig_sender)
BIC in F56 of the message.
(mtf1000.ibk_bic)
Originating
Bank A
BIC in F52 of the message
(mtf1000.ogb_bic)
Sender of the message
(Mif.orig_sender)
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 39
Field Name in
Algorithm
Field in Payment
Field in 210
(Bank specific for MT191)
(Bank specific for MT191)
Originating
Bank B
If a BIC exists in F52 then F52 BIC Else
Sender of the message
(If Mtf1000.ogb_bic exists then
Mtf1000.ogb_bic
Else
Mif.orig_sender)
BIC in F52 of the message. if the field
is empty, then the originator is not
available for matching
(Mtf1000.ogb_bic)
Credit party
If F58 is “1st in Chain” then Account
number in F58 if exists, or the Single
non-asset-account of the beneficiary in
F58A, or the preferred non-asset
account of the beneficiary in F58A. Else
the Credit Party is not available for
matching (i.e. Matching steps containing
this field will be skipped).
Account number account in F25 if
exists, or the Single Account of the
Sender, or the Preferred Account of
the Sender. Else the Credit Party is not
available for matching (i.e. Matching
steps containing this field will be
skipped).
(mtf1000.cr_acc_no)
Beneficiary
Account
MTF1000.BNF
(Customer in Field 59 in a 103 or Field
58 in a 202)
Account number in F25 if exists, or the
Single Account of the Sender, or the
Preferred Account of the Sender. Else
the Credit Party is not available for
matching (i.e. Matching steps
containing this field will be skipped).
(mtf1000.cr_acc_no)
Originating
Party
Corresponding Party (either F50 or F52)
Mtf1000.Org
Mtf1000.Org_Id
Mtf1000.Org_Bic
Mtf1000.Org_Addr1
Mtf1000.Org_Addr2
Mtf1000.Org_Addr3
Or
Mtf1000.Ogb
Mtf1000.Ogb_Id
Mtf1000.Ogb_Bic
Mtf1000.Ogb_Addr1
Mtf1000.Ogb_Addr2
Mtf1000.Ogb_Addr3
Corresponding Party (either F50 or
F52)
Mtf1000.Org
Mtf1000.Org_Id
Mtf1000.Org_Bic
Mtf1000.Org_Addr1
Mtf1000.Org_Addr2
Mtf1000.Org_Addr3
Or
Mtf1000.Ogb
Mtf1000.Ogb_Id
Mtf1000.Ogb_Bic
Mtf1000.Ogb_Addr1
Mtf1000.Ogb_Addr2
Mtf1000.Ogb_Addr3
2.5.4.1.2 210 Predefined Matching Actions
1. The predefined matching actions are different methods according to which GPP scans the
payment and the MT210 messages when searching for a possible matching. Each action
describes different searching method. The actions use the comparison fields to detect a matching.
2. There are following predefined matching actions (methods):
a. Rule action 210-1
b. Rule action 210-2
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 40
c. Rule action 210-3
d. Rule action 210-4
e. Rule action 210-5
f. Rule action 210-C
g. Rule action 210-6
h. Rule action 210-0
i. Rule action 210-J
j. Rule action 210-CNA
k. Stop action
l. Rule action 210-IF
2.5.4.1.2.1 Rule Action 210-1
Search Scenario Steps:
1. Match by Amount, Value Date, Currency and Originating-Bank-B.
If is match was found it is considered a full match.
If a match was not found search according to the next step
2. Match by Amount + / - Tolerance, Value Date, Currency and Originating-Bank-B
If is match was found it is considered a full match.
If a match was not found search according to the next step
Match by Amount + / - Tolerance, Value Date, Currency
If is match was found it is considered a possible match.
Steps 1-2:
Search for messages with 210-match status equal to W or P, if the matched payment is SN it is a
210MATCHSN, otherwise 210MATCH
Step 3:
If payment: Search for messages with 210-match status equal to W or P
If 210: Search for messages with 210-match status equal to W
3. Returned values in case of a full match: None
2.5.4.1.2.2 Rule Action 210-2
Search Scenario Steps:
1. Match by currency, special reference, amount and value-date
If is match was found it is considered a full 210MATCHSN
If a match was not found search according to the next step.
2. Match by currency, amount and value-date.
If is match was found it is considered a possible 210POSAMT match
If a match was not found search according to the next step
3. Match by currency, special reference and value-date
If is match was found it is considered a possible 210POSREF match
Step 1:
GPP searches for messages with 210-match status equal to W or P.
Steps 2-3:
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 41
If this matching was activated on a payment, GPP Searches for 210 messages with 210-match
status equal to W or P.
If this matching action was activated on an MT210, GPP Searches for messages with 210-match
status equal to W.
4. Returned values in case of a full match: None
2.5.4.1.2.3 Rule Action 210-3
Search Scenario Steps:
1. Single match (count = 1) by: Reference, Currency, Paying Bank, Value Date, Office and Amount
+ / - Tolerance
If is match was found it is considered a full match.
If a match was not found search according to the next step
2. First of multiple matches (count >1) by: Reference, Currency, Paying Bank, Value Date, Office
and Amount + / - Tolerance. Order by difference in amounts and take smallest difference.
If a match was found it is considered a full match.
If a match was not found search according to the next step
3. First Match by: Currency, Paying Bank, Value Date, Office and exact Amount
If a match was found it is considered a possible match.
Step 1:
GPP Searches for messages with 210-match status equal to W or P.
Steps 2-3:
GPP Searches for messages with 210-match status equal to W.
4. Returned values in case of a full match: Credit account and Related reference number of the
MT210
2.5.4.1.2.4 Rule Action 210-4
Search Scenario by Steps:
1. First Match by: Reference, Currency, Office and Amount + / - Tolerance
If a match was found it is considered a full match.
If a match was not found search according to the next step
2. First Match by: Reference, Currency and Office
If a match was found it is considered a possible match by reference 210POSREF
If a match was not found search according to the next step
3. First Match by: Amount, Currency and Office
If a match was found it is considered a possible match by amount 210POSAMT
Steps 1-3:
GPP Searches for messages with 210-match status equal to W or P.
4. Returned values in case of a full match: Credit account and Related reference number of the
MT210
2.5.4.1.2.5 Rule Action 210-5
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 42
Search Scenario Steps:
1. First Match by Amount, Value Date, Currency and Originating-Bank-B
If a match was found it is considered a full match
If a match was not found search according to the next step
2. First Match by Amount + / - Tolerance, Value Date, Currency and Originating-Bank-B
If a match was found it is considered a full match
If a match was not found search according to the next step
3. First Match by Amount + / - Tolerance, Value Date, Currency
If a match was found it is considered a possible match by amount 210POSAMT
Steps 1-2:
GPP Searches for messages with 210-match status equal to W or P.
Step 3:
If payment: GPP searches for MT210 with 210-match status equal to W or P
If 210: Search for payment messages with 210-match status equal to W
4. Returned values in case of a full match: Credit account and Related reference number of the
MT210
2.5.4.1.2.6 Rule Action 210-C
Search Scenario Steps:
1. First Match by Amount, Value Date, Currency, Originating-Bank B and Credit Party
If a match was found it is considered a full match
If a match was not found search according to the next step
2. First Match by Amount + / - Tolerance, Value Date, Currency, Originating-Bank B and Credit Party
If a match was found it is considered a full match
If a match was not found search according to the next step
3. First match by Amount, Value Date, Currency, Originating Bank B and reference is a full match
If a match was found it is considered a full match
If a match was not found search according to the next step
4. Any match by Amount +/- tolerance, Value Date, Currency, Originating Bank B and reference
If a match was found it is considered a possible match by amount 210POSAMT
If a match was not found search according to the next step
5. Any match by Amount +/- tolerance, Value Date, Currency, Credit Party
If a match was found it is considered a possible match by amount 210POSAMT
If a match was not found search according to the next step
6. Any match by Amount +/- tolerance, Value Date, Currency and Originating Bank B
If a match was found it is considered a possible match by amount 210POSAMT
7. Returned values in case of a full match: Credit account and Related reference number of the
MT210
2.5.4.1.2.7 Rule Action 210-6
Search Scenario Steps:
1. First Match by: Reference, Currency, Office and Amount + / - Tolerance
If a match was found it is considered a full match.
If a match was not found search according to the next step
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 43
2. First Match by: Special Reference, Currency, Office and Amount + / - Tolerance
If a match was found it is considered a full match.
If a match was not found search according to the next step
3. First Match by: Reference, Currency and Office
If a match was found it is considered a possible match by reference 210POSREF
If a match was not found search according to the next step
4. First Match by: Special Reference, Currency and Office
If a match was found it is considered a possible match by reference 210POSREF
If a match was not found search according to the next step
5. First Match by: Amount, Currency and Office
If a match was found it is considered a possible match by amount 210POSAMT
Steps 1-3:
GPP Searches for messages with 210-match status equal to W or P.
2.5.4.1.2.8 Rule Action 210-J
This rule is relevant when settlement amount is used in the 210 advice by the sender, but is different
from the instructed amount in the payment (33B), because of FX conversions or fee charges.
Search Scenario Steps:
1. First Match by: Beneficiary Account, Value Date, Currency and Amount
If a match was found, set 210 match status = M.
2.5.4.1.2.9 Rule Action 210-CNA
Search Scenario Steps:
1. First Match by: Amount + / - Tolerance
1
, Value Date, Currency, Credit Account
If a match was found, set 210 match status = M and continue with step 2
If a match was not found, no matching will be done.
2. First Match by: Amount + / - Tolerance, Value Date, Currency, Credit Account, Related Reference
(Payment F21 against 210 F20) - if exist
If a match was found, set 210 match status = M and continue with step 4.
If a match was not found, continue with step 3
3. First Match by: Amount + / - Tolerance, Value Date, Currency, Credit Account, Originating Party
(ORG/OGB)
If a match was found, set 210 match status = M, Select first record from step 3 as possible match
and set 210 match status = P.
If a match was not found, select first record from step 1 as possible match and set 210 match
status = P
4. First Match by: Amount + / - Tolerance, Value Date, Currency, Credit Account, Originating Party
(ORG/OGB), Related Reference (Payment F21 against 210 F20) - if exist
1
Tolerance is taken from credit account profile and if not found, from system option MATCHTOLRN. It is expressed in percentage of the amount
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 44
If a match was found, set 210 match status = M. Select first record from step 4 as possible match
and set 210 match status = P.
If a match was not found, select first record from step 2 as possible match and set 210 match
status = P
2.5.4.1.2.10 Rule Action 210-0
1. This rule will be used in cases where we want the payment/210 to be eligible for matching but not
to execute any searches.
2. Returned values in case of a full match: None
2.5.4.1.2.11 Stop
1. The STOP action is used to stop evaluating rules.
2. If a rule with the STOP action fits the message, then GPP will not evaluate any further rules and
behave as if no fitting rule was found. In the context of 210 Matching Rules, this means that 210
Matching status will be N.
2.5.4.1.2.12 Rule Action 210-IF
Match the incoming payment’s to the MT210’s attributes based on the below mentioned criteria.
Note: In steps 1 to 5, GPP performs the search where Payment Message is ‘Non Feeder’ and ‘Non
Manual Payments’ i.e. Orig MOP <> FEEDER, CREATE.
Search Scenario Steps:
1. First Match by F32 Settlement Amount and Currency, F32 Value Date, Originating-Bank
(compare against 52A, (11 or 8 characters BIC)), if F52 is not present then the Sender (11 or 8
character BIC) and Credit Party full 14 digits account number.
If a match is found, it is considered as a full match.
If a match is not found, search as per step 2.
2. First Match by F32 Settlement Amount + / - Percentage Tolerance (Refer System option
MATCHTOLRN_IN_MT210) and Currency, F32 Value Date, Originating-Bank (compare against
52A, (11 or 8 character BIC)), if not present then the Sender (11or 8 character BIC) and Credit
Party full 14 digit account number.
If a match is found, it is considered as a Partial Match by Amount.
If a match is not found, search as per step 3.
3. First Match by F32 Settlement Amount and Currency, Originating-Bank (compare against 52A,
(11 or 8 character BIC)), if not present then the Sender (11 or 8 character BIC) and Credit Party
full 14 digit account number.
If a match is found, it is considered as a Partial Match by Amount.
If a match is not found, search according to the next step 4.
4. First Match by F32 Settlement Amount + / - Percentage Tolerance (Refer System option
MATCHTOLRN_IN_MT210) and Currency, Originating-Bank (compare against 52A,(11 or 8
character BIC)), if not present then the Sender (11 or 8 character BIC) and Credit Party full 14
digit account number.
If a match was found, it is considered as a Partial Match by Amount.
If a match is not found, search according to the next step 5.
5. First Match by F32 Settlement Amount and Currency, F32 Value Date, F21 Related Reference
and Credit Party full 14 digit account number.
If a match was found, it is considered as a Partial Match by reference.
If a match was not found, then conclude as No Match search according to the next step.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 45
Steps 6 to 7 where payment message is an incoming MT103 or MT103 (Msg_Type=103)
spawned out of MT101 payment message to MT210 messages received earlier.
Search Scenario Steps:
1. For messages from Source Feeder - First Match by F32 Settlement Amount and F32 Currency,
F32 Value Date and Customer reference F20. (currently references in code word DNAR,
EPAREF and ROLREF are replaced to F20 when message is received in GPP)
If a match was found, consider it a Partial Match by reference.
If a match was not found, then go to step 7.
2. Match by F32 Settlement Amount and F32 Currency, F32 Value Date.
If a match is found, consider it a Partial Match by amount.
If a match is not found, conclude it as No Match.
Step 8 payment message is the incoming 202, 202COV or 202 spawned out of 203 to MT210
messages received earlier.
Search Scenario Steps:
3. For messages from Source Feeder - First Match by F32 Settlement Amount and F32 Currency,
F32 Value Date, against Field 21.
If a match was found, consider it a Partial Match by amount.
If a match is not found, conclude it as No Match.
Step 1:
GPP Searches for messages with 210-match status equal to W or P.
Steps 2-8:
If this matching was activated on a payment, GPP searches for 210 messages with 210-match
status equal to W or P.
If this matching action was activated on an MT210, GPP searches for messages with 210-match
status equal to W.
2.5.4.1.3 210 Matching Scope
1. The scope of MT210 matching is to match payments and credit advices and unsolicited debit
advices (MT103, MT202, MT205, MT910, MT900) on the one hand with MT210s or any other
form of Anticipated Funds on the other.
2. MT210 Matching can be performed either automatically by setting up 210 Matching rules or
manually via the 210 reconcile screen
MT210 Types
1. GPP supports the following MT210 types
- MT210 received from a customer indicating funds to be received to customer’s credit. This
same MT210 may also indicate the bank’s Nostro where funds will be received. The Dr
account is the Nostro; the Cr account is the customer account.
- MT210 sent from the bank to its Nostro agent indicating funds to be received at the Nostro
from a third part. This MT210 may originate within bank’s different departments and will be
on-warded, if required, to the financial institution that services the Nostro account specified in
the MT210. This same MT210 may also indicate the party from which the Nostro will receive
the funds. The Dr account is the Nostro, the Cr account is the customer account.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 46
- Internal MT210 that indicates anticipated receipt into a Nostro account and a customer
account. This MT210 is not on-warded. The Dr account is the Nostro, the Cr account is the
customer account.
- Reverse MT210 - MT210 indicating anticipated funds to be withdrawn from a Nostro account
held at another bank. This MT210 is not on warded by GPP. The Cr account is the Nostro
account.
2. MT210s will be matched with payments as follows:
- ANY payment that debits a Nostro is a candidate for matching to MT210s of type (a) – (c)
above.
- ANY payment that credits a Nostro is a candidate for matching to MT210 of type (d) above.
2.5.4.1.4 MT210 Anticipated Funds Recognition
In order to consider an MT210 as anticipated funds, GPP activates the following steps:
Accounts derivation
Eligibility for matching
Matching rules
2.5.4.1.5 Account Derivation
1. GPP first attempts to identify both the debit and credit accounts of the transaction that will match
to the MT210.
2. The following table describes the criteria upon which GPP determines the debit and credit
accounts involved in an MT210:
Reverse
210
Sender
Receiver
Dr Account
Cr Account
No
Local bank
Local bank
An asset account associated
with the BIC mentioned in field
56, or Default Account per
Payment Currency when field 56
is empty
The account mentioned
in field 25
No
Local Bank
Other
The account mentioned in field
25, or the local bank asset
account with the Receiver when
field 25 is empty
N/A2
No
Other Bank
Local Bank
An asset account associated
with the BIC mentioned in field
56 , or the default Account per
Payment Currency when field 56
is empty
Account in field 25, or
the Senders non asset
account with the local
bank when field 25 is
empty
Yes
Local bank
Local bank
N/A
An asset account
associated with the BIC
mentioned in field 56, or
the default account per
2
Example: We send an MT200 to our Nostro B to transfer funds to Nostro C, and an MT210 to Nostro C. We expect to receive an MT910 from
Nostro C that will match the MT210. The accounts of such a transaction are: Dr Nostro C, Cr Nostro B. From an MT210 perspective Nostro B is
not a relevant party, therefore we do not derive, in this scenario, a credit account for the MT210.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 47
Reverse
210
Sender
Receiver
Dr Account
Cr Account
Payment Currency
when field 56 is empty
3. As part of MT210 credit account identification process, GPP will search for account by account
number first (ACCOUNTS.ACC_NO), If not found then by IBAN (ACCOUNTS.IBAN).
4. If GPP is unable to identify both the debit and the credit accounts, the MT210 match status is
changed to N and the MT210 is not eligible for matching and is sent to the COMPLETE queue.
2.5.4.1.5.1 Eligibility for Matching
1. GPP determines whether the MT 210 is eligible for matching when at least one of the accounts
(debit or credit accounts) is eligible for matching. An account is considered eligible for matching
when the account has the 210 matching indication checked in the Account profile.
2. When both accounts are not eligible for matching, the MT210 message class is changed to NAC,
the 210 match status is changed to N and the MT210 is not eligible for matching and is sent to the
COMPLETE queue
2.5.4.1.5.2 210 Automatic Matching Rules
1. 210 Matching rules are invoked on payment messages after debit processing and after 1st in
credit chain identification, but before PI/SN matching and Credit processing.
2. GPP invokes automatic matching on the following payments:
- Incoming payments with message class PAY, PI, SN, DD, provided that the 1st in credit chain
is the final beneficiary (i.e. – that the payment will not be on-warded).
- PAY, PI and SNs are matched to non-reverse MT210s.
- DD are matched to reverse-210s. The source of the MT210 is irrelevant.
3. To invoke the rules on MT210s, GPP evaluates the default rules attached to the Local Bank in
their attachment order.
4. To invoke the rules on payments, GPP evaluates the rules attached to the 1st in credit chain, and
if no fitting rule is found, GPP evaluates the default rules attached to the Local Bank in their
attachment order.
5. If a fitting rule is not found, then there will be no attempt to match the payment to an MT210 or
vice versa, and the payment or MT210 is assigned a 210-match status N (not for matching). In
such case the MT210 message class is changed to NAC (non-accounting) message.
6. If a fitting rule is found, GPP first assigns 210-match status W (waiting) to the payment or to the
MT210, and then uses the matching action of the rule to attempt to match the payment to a
previously received un-matched MT210 or the MT210 to a previously received un-matched
payment message. In case the payment does not find a matching MT210 or a possible match
MT210, then the message is processed to completion.
7. GPP allows a payment message to be possibly matched to a single 210, but allows an MT 210 to
be possibly matched to multiple payments.
8. In any case, whether a fitting rule is found or not, the MT210 is sent to the COMPLETE queue
and the payment processing continues.
2.5.4.1.6 210 Matching Statuses
1. The result of the matching rule and the action associated with it may lead to the following possible
matching statuses:
- N - Not applicable for Matching, this status is received when:
GPP recognizes that both the debit and the credit parties of the MT 210 are not eligible for
matching
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 48
When a matching rule was not found
By a user decision to manually modify the status value.
- W - Waiting Match, this status is received when:
› When the automatic matching rules were applied but no matching message was found
› When the automatic matching rules were applied and the selected algorithm is 210-0
- M – Matched, this status is received when a payment message was matched either
automatically or manually to a payment that is not an SN
- S - Matched to SN, this status is received when an MT210 was matched to an SN message,
or to a PI that was previously matched to an SN - either automatically or manually
- P - Possibly matched, this status is received when GPP applied a matching algorithm which
resulted in a possible match and not a full match. There are 2 types of possible matches: By
amount or by reference. A user should manually resolve the possible match (by either
manually confirming the match or manually un-matching).
2.5.4.1.7 Post 210 Matching Activities
Once a payment message was matched with an MT210 either automatically or manually, the
following activities occur:
2.5.4.1.7.1 Copy 210 Reference
1. Copy the 210 reference to the payment message-related reference, relevant only for non-reverse
MT210.
- Payment Attributes –210 Reference Switching. The system automatically sets the value of
this field to one of the values:
› N - (no 210 match) the default value
› M - (210 match with no reference switching),
› R - (210 reference switching invoked).
- Payment Processing - before a full successful match, the payment attribute 210 Reference is
empty and the payment attribute ‘210 Reference switching’ is set to N (no 210 match). After a
full successful 210 match (either automatic or manual), GPP checks the payment credit
account attribute ‘210 reference switching’ and performs the following:
› If it is None, GPP leaves the payment attribute ‘210 Reference’ empty and sets the
payment attribute ‘210 Reference Switching’ to M (210 match with no reference
switching).
› If it is F20, GPP sets the payment attribute ‘210 Reference’ to the contents of field 20 of
the incoming MT210, and sets the payment attribute ‘210 reference switching’ to R (210
reference switching invoked).
› If it is F21, GPP sets the payment attribute ‘210 Reference’ to the contents of field 21 of
the incoming MT210, and sets the payment attribute ‘210 reference switching’ to R (210
reference switching invoked).
2.5.4.1.7.2 Copy Account Number
1. In the case of a non-reverse MT210s, the 210 account number is copied into the payment
attribute 210 Account number, provided that the matching algorithm returns the credit account
number of the MT210.
2. This is subsequently used in payment credit account derivation:
GPP decides on the credit account in the following order of priority:
a. Account entered by user
b. Credit Processing Profile – Override account
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 49
c. Account from message
d. Account from matched 210 z
e. Credit Processing Profile – Default account
2.5.4.1.7.3 Post Match Relation Cleanup
Once a payment message and an MT210 are matched either manually or automatically, the following
occurs:
The matched MT210 was a possible candidate for other payments – all such links will be deleted.
If such payments do not have any other MT210s that is defined as possible candidate, their 210
status changes to W – waiting to be matched, instead of P – possible match. GPP re-invokes the
matching mechanism in order to detect their actual matching status.
The matched payment had other possible candidates – all the links will de deleted. If such
MT210s are no longer linked to any other payment, their 210 status changes to W – waiting to be
matched, instead of P – possible match. GPP re-invokes the matching mechanism in order to
detect their actual matching status.
2.5.4.1.7.4 Archiving MT210 Messages
Unmatched incoming MT210 messages may be retained for a longer period of time than regular
payments as defined in system option - 210KEEP.
To calculate which PI messages to move/clean GPP takes the Local Office business date minus the
number of days set in system option 210KEEP.If the result is less than the payment value date and
receipt date then the payment is moved to the history database. The parameter is set for a number
and defines the number of working days.
2.5.4.2 Nostro Account Position
2.5.4.2.1 Anticipated Funds Positioning
1. Un-matched anticipated funds to be received at a Nostro account will be reflected as credit
anticipated funds
2. Un-matched anticipated funds to be withdrawn from a Nostro account will be reflected as the debit
anticipated funds
3. The amount of already matched MT210s will not be taken into consideration by the Nostro
account position as the matched payment amount is already reflected
4. MT210 marked as NAC – will not impact the Nostro account positioning
2.5.4.2.2 PI/SN Positioning
1. PI messages - The amount of PI messages for a specific value date which are still in the
PAYSET queue is reflected in the not-yet settled credit figure on the Nostro Account Position
screen.
Once matched (either manually or automatically) or forced out of the PAYSET queue, the amount
of the PI messages is no longer be taken into consideration as Not-yet settled funds, and is added
to the settled credit figure.
2. SN messages – when an SN receives the complete status its amount is added to the settled
payment figure on the Nostro Account Position screen.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 50
2.5.5 Message Data
2.5.5.1 210 Matching
2.5.5.1.1 210 Reconcile
1. The 210 Reconcile functionally enables manually matching of a payment message with an
MT210s. The 210 reconcile is performed via the Reconcile 210 option on the Messages menu or
via GPP different queues (e.g. Complete queue).
2. Using the 210 reconcile feature, a user can perform the following:
- Create a match between an MT210 and a payment message
- Confirm a possible match between an MT210 and a payment message
- Un-match a possible match between an MT210 and a payment message
3. The manual reconcile option is activated by using the “210” button on the queue-toolbar. This
button is available in the following queues:
- AGED
- COMPLETE
- HELD
- NSF
- PAYSET
- RECON210 (accessible via the Message Menu)
- RELEASE
- SCHEDULE
4. The following table summarizes the possible reconcile activities that can be performed via the
Reconcile screen.
Activity
Description
Match
Used to match a 210 and a payment, or to confirm a possible match between a
210 and a payment.
Show Matched …
Used to display in the lower half the messages that are fully matched to the
highlighted message in the upper half.
Show Poss …
Used to display in the lower half the messages that are possibly matched to
the highlighted message in the upper half.
Show All …
Used to display in the lower half all messages that may be applicable for
matching to the highlighted message in the upper half.
Un-match
Used to un-match the highlighted message in the lower half from the
highlighted message in the upper half.
5. A payment in PAYSET queue can be opened and edited. The payment can be repaired,
submitted and subjected to skip / verify rules.
Reference: See the Manual payment handling functional specifications document for details.
2.5.5.1.2 210 Reconcile via the Message Menu
1. When opening the reconcile screen via the message options, a list of all MT210 that are either
waiting to be matched or are possible matches is presented.
Message Types SWIFT Processing
Global PAYplus | Message Types | Business Guide Page 51
2. By clicking the MT210 Reconcile icon, the screen is split. On the upper part of the screen the user
can view a list of the still unmatched MT210, while on the lower part the user can view a list of
relevant to MT210 matching payment messages.
3. The contents of the lower part of the screen are dynamically changed in accordance to the
highlighted MT210 in the upper part of the screen as follows:
Highlighted Message in
Upper Half
List of Messages in Lower Half
Non-reverse MT210
waiting for a match
All un-matched or possibly matched payments with message class PAY,
PI or SN, with the same currency as the highlighted MT210, and with an
amount within a certain tolerance of the MT210 amount. As specified by
MATCHTOLMN system option.
Reverse MT210 waiting
for a match
All un-matched or possibly matched payments with message class DD,
with the same currency as the highlighted MT210, and with an amount
within a certain tolerance of the MT210 amount. As specified by
MATCHTOLMN system option.
MT210 Possibly matched
All possibly matched payments
4. The user can scroll between the payment messages displayed on the lower part of the screen.
When a matching payment message is found, the user can match between the MT210 and the
payment message by clicking the Match icon.
2.5.5.1.3 210 Reconcile via GPP queues
The 210 Reconcile option may be accessed also from different GPP queues (e.g. Complete queue)
by clicking the 210 Reconcile icon. The screen is split into two parts.
- On the upper part of the screen the user can view all the messages that reside in that queue
regardless of the message type, meaning the upper part of the screen lists MT210, payment
messages or credit advices.
- On the lower part of the screen, GPP dynamically displays relevant candidates for 210
matching according to the highlighted message on the upper part of the screen. Thus if a
payment message is highlighted on the upper part of the screen, GPP displays all MT210 that
are candidates for matching with the payment message. Vice versa if an MT210 is highlighted
on the upper part of the screen, GPP displays all payment messages that are candidates for
matching with the highlighted MT210 message.
Highlighted Message in
Upper Half
List of Messages in Lower Half
Non-reverse MT210
waiting for a match
All un-matched or possibly matched payments with message class PAY,
PI or SN, with the same currency as the highlighted MT210, and with an
amount within a certain tolerance of the MT210 amount. As specified by
MATCHTOLMN system option
Reverse MT210 waiting
for a match
All un-matched or possibly matched payments with message class DD,
with the same currency as the highlighted MT210, and with an amount
within a certain tolerance of the MT210 amount as specified by
MATCHTOLMN system option
MT210 Possibly matched
All possibly matched payments
MT210 fully matched
The fully matched payment
Message Types ISO 2022 Processing
Global PAYplus | Message Types | Business Guide Page 52
Highlighted Message in
Upper Half
List of Messages in Lower Half
Payment with message
class PAY, PI or SN
waiting for a match
All un-matched or possibly matched non-reverse MT210s with the same
currency as the highlighted payment, and with an amount within a certain
tolerance of the payment amount as specified by MATCHTOLMN system
option
Payment with a message
class DD waiting for a
match
All un-matched or possibly matched reverse MT210s with the same
currency as the highlighted payment, and with an amount within a certain
tolerance of the payment amount as specified by MATCHTOLMN system
option
Payment possibly
matched
Possibly matched MT210
Payment fully matched
The fully matched MT210
2.5.5.1.4 Repairing MT210
1. A 210 may fall to repair when the tag 25 is empty and multiple accounts are derived with any of
the following option:
- none preferred, or
- multiple preferred accounts are found, or
- receipt of an invalid credit account
In this case, GPP is not be able to derive a credit account.
2. In the repair screen, it is possible to update / insert a credit account.
3. Once the MT210 is repaired, the system reassess whether a matching payment can be found.
2.5.5.2 View Messages Relations
1. Message relationships, e.g. PI/SN matched messages, 210 matched messages, are maintained
and stored in GPP database.
2. This information can be viewed via the Linked Messages screen by clicking the Links icon. The
screen lists all messages that are related to the current message.
3 ISO 2022 Processing
3.1 camt.054 Message
camt.054 is a bank to customer debit/credit notification message. It provides a settlement view of all
settled transactions and is an alternative to MT900 (Confirmation Debit), and MT910 (Confirmation
Credit). The use of camt.054 format provides a uniform mapping in a standard format, certified by
ISO20022.
GPP can generate a camt.054 notification message for single transactions and only includes single
transactions that are settled (for example, accounting transactions).
camt.054 messages are generated with status BOOK (BOOK = camt.054 message status) and sent
to the required creditors and debtors.
These are the supported use cases:
Creditor notification for settled transactions - Incoming credit transfer
Debtor notification for settled transactions - Outgoing credit transfer
Message Types ISO 2022 Processing
Global PAYplus | Message Types | Business Guide Page 53
Creditor and debtor notifications for settled transactions - Credit transfer on us
Debtor notification for settled transactions - Incoming Direct Debit
Original Debtor notification for settled return
Original Creditor notification for settled refund/reversal
Original Debtor notification for settled refund/reversal
Creditor notification for settled transactions - Incoming bulk credit transfer
Debtor notification for settled transactions - Incoming bulk direct debit
Global PAYplus | Message Types | Business Guide Page 54
Appendix A: Glossary
This table provides definitions for terms used in this document.
Term
Description
Child Message
De-bulked individual payment message
DB
Database
FI
Financial Institution
GPP
Global PAYplus
MUG
Message User Group
NAC
Bulk Message Class: Non-Accounting message, such as that used for non-
debit lump sum mode
Parent Message
Bulked message
PAY
Bulk Message Class: Accounting message, such as that used for debit lump
sum mode
PDO
Payment Data Object
STP
Straight-Through Processing
UI
User Interface, also referred to as GUI (graphical user interface)

Navigation menu