Business Guide GPP Message Types

User Manual: Pdf

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

DownloadBusiness Guide GPP Message Types
Open PDF In BrowserView PDF
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 a ny
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 selectio ns
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.

Version Control
Version

Date

1.0

Summary of Changes
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 3

Table of Contents
1

INTRODUCTION .................................................................................................................... 5
1.1
1.2
1.3
1.4

2

Overview .......................................................................................................................... 5
SWIFT Messages............................................................................................................. 6
ISO 20022 Message Standards ........................................................................................ 8
Target Audience............................................................................................................... 8
SWIFT PROCESSING ............................................................................................................ 8

2.1
2.1.1
2.1.2
2.1.3
2.1.4
2.1.5
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.3
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.5
2.5.1
2.5.2
2.5.3
2.5.4
2.5.5
3

MT101 Message .............................................................................................................. 8
Overview ...................................................................................................................... 9
Processing.................................................................................................................. 10
Manual Handling......................................................................................................... 17
Business Setup........................................................................................................... 17
Message Data ............................................................................................................ 18
MT102 Message ............................................................................................................ 19
Overview .................................................................................................................... 19
Processing.................................................................................................................. 20
Manual Handling......................................................................................................... 25
Business Setup........................................................................................................... 25
Message Data ............................................................................................................ 27
MT203 Message ............................................................................................................ 28
Overview .................................................................................................................... 28
Processing.................................................................................................................. 29
Manual Handling......................................................................................................... 31
Business Setup........................................................................................................... 32
Message Data ............................................................................................................ 32
MT204 Message ............................................................................................................ 32
Overview .................................................................................................................... 32
Processing.................................................................................................................. 33
Manual Handling......................................................................................................... 36
Business Setup........................................................................................................... 36
Message Data ............................................................................................................ 36
MT210 Message ............................................................................................................ 37
Overview .................................................................................................................... 37
Processing.................................................................................................................. 37
Manual Handling......................................................................................................... 38
Business Setup........................................................................................................... 38
Message Data ............................................................................................................ 50

ISO 2022 PROCESSING ...................................................................................................... 52
3.1

camt.054 Message ......................................................................................................... 52

APPENDIX A: GLOSSARY ............................................................................................................. 54

Global PAYplus | Message Types | Business Guide

Page 4

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 5

-

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

SWIFT_198

557

Proprietary message

SWIFT_198
SWIFT_199

Free format message

SWIFT_200

Financial institution transfer for For format and rules refer to
each own account
SWIFT Book/Category 2/MT200

SWIFT_202

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

COV

RVR

Notice to receive

Global PAYplus | Message Types | Business Guide

Page 6

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

SWIFT_900

Debit confirmation

SWIFT_910

950

For format and rules refer to
SWIFT Book/Category 4/MT400

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 7

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 8

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 9

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 Logical ID
Field Name

Alias

GPP DB Comments
Table

1.

NA

P_MID

MID

MINF

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 Orgnl msg tp
E

MINF

SWIFT_101

11.

NA

P_DISPLAY_MSG_T Display Msg tp
YPE

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 Orgnl Instg agt
C_2AND
BIC 2

Global PAYplus | Message Types | Business Guide

System generated

XML_OR
IG_MSG

Page 10

No

SWIFT Tag & Field Logical ID
Field Name

16.

Orig Receiver OX_INSTD_AGT_BI Orgnl instd agt
BIC 2
BIC in Block C_2AND
1

2.1.2.2

Alias

GPP DB Comments
Table
XML_OR
IG_MSG

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 11

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 12

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 13

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 14

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 Display Msg tp
E

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_ Orgnl Instg agt
2AND
BIC 2

XML_ORI
G_MSG

32.

Orig Receiver
BIC in Block 1

OX_INSTD_AGT_BIC_ Orgnl instd agt
2AND
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 15

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 fieldX_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 16

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
2.1.4.1.1

Business Rules
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 17

Rule
Name

Rule
Sub
Type

MAP_F None
EE_AC
CT

2.1.4.1.2

Description

Attached
to

And
/Or

Set debit fee
Local office
account on
MT103,
And
generated from
MT101 with
F25
And

Field/F Operator
ield

Value

[Msg
tp]

SWIFT_ MAP_FEE_
103
ACCT

=

[Orgnl =
msg tp]

SWIFT_
101

[Orgnl
fee
acct]

Empty

Is not

Action

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

MAP_FEE_
ACCT

Rule
Sub
Type

Description

Field/Field

Operator

Value

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 18

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





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





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.

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 19

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 20

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 21

MT102 Multiple MT103 Single
Customer
Customer Credit
Credit Transfer 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 22

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

71F

Sender's Charges

3!a15d

20.
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 Field Logical ID
Name

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 23

No

Status

SWIFT Tag & Field Field Logical ID
Name

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

71F

Sender's Charges

3!a15d

49.
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, feerelated 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 24

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
2.2.4.1.1

Business Rules
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

INC_B N/A
ULK_M

Description

Attached
to

Select Credit
MOP=BOOK

Local office

Global PAYplus | Message Types | Business Guide

AND/
OR

Field/
Field

Operator

Value/
Field/
Function

Action

[Msg tp]

=

SWIFT_10 BOOK
2

Page 25

Rule
Name

Rule
Sub
Type

SG_10
2

2.2.4.1.2

Description

Attached
to

AND/
OR

Field/
Field

Operator

Value/
Field/
Function

Action

for incoming
bulk
messages 102
and 102 STP;
should not
exceed 1000
characters

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

INC_B N/A
ULK_M
SG_10
2

2.2.4.1.3

Description

Attached
to

Select Local
Office’s party
for bulk
MT102 and
MT102 STP if
processed as
PAY

Local office

AND/
OR

Field/
Field

Operator

Value/
Field/
Function

Action

[Msg tp]

=

[Msg
class]

=

SWIFT_10 
Usage:
Replace
PAY
First

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

INC_B N/A
ULK_M
SG_10
2

2.2.4.1.4

Description

Attached
to

AND/
OR

Select credit
Local office
suspense
account for
the single
debit posting
for MT102 and
MT102 STP

Field/
Field

Operator

Value/
Field/
Function

Action

[Msg tp]

=

[Msg
class]

=

SWIFT_10 
Usage:
Override
account

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 26

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

INC_B N/A
ULK_M
SG_10
2

Description

Attached
to

BI-bypass for
bulk
messages
MT102 and
MT102 STP,
which are
processed in
GPP as PAY
messages

Local office

AND/
OR

Field/
Field

Operator

Value/
Field/
Function

Action

[Msg tp]

=

SWIFT_10 BYPASS
2

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

Global PAYplus | Message Types | Business Guide

Page 27

Message Types

SWIFT Processing

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.

Global PAYplus | Message Types | Business Guide

Page 28

Message Types

SWIFT Processing

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

Global PAYplus | Message Types | Business Guide

Page 29

Message Types

2.3.2.2

SWIFT Processing

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

Global PAYplus | Message Types | Business Guide

Page 30

Message Types

SWIFT Processing

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 Field Logical ID
Name

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.

Global PAYplus | Message Types | Business Guide

Page 31

Message Types

SWIFT Processing



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.

Global PAYplus | Message Types | Business Guide

.

Page 32

Message Types

SWIFT Processing

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

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.

Global PAYplus | Message Types | Business Guide

Page 33

Message Types

SWIFT Processing



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

Global PAYplus | Message Types | Business Guide

Page 34

Message Types

SWIFT Processing

Original Incoming MT204

Logical Fields
*Including all sub-fields*

72

2.4.2.3

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*

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

Global PAYplus | Message Types | Business Guide

Page 35

Message Types

SWIFT Processing

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
2.4.4.1.1

Profiles
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

Global PAYplus | Message Types | Business Guide

Page 36

Message Types
o
2.4.5.2

SWIFT Processing

MOP = SWIFT
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.

Global PAYplus | Message Types | Business Guide

Page 37

Message Types

2.5.2.5

SWIFT Processing

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

Currency

Currency in F32A or F72/OCMT/ or
Currency in F32B of the message
F33B of the message (Mif.orig_currency (Mif.currency)
or mif.ocmt_currency or
mif.instruct_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 Amount in F32B of the message
of the message.
(Mif.amount)
(Either Mif.orig_amount or
mif.ocmt_amount or
mif.instruct_amount, depending on the
first currency field that was matched)

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)

Global PAYplus | Message Types | Business Guide

Field in 210

Page 38

Message Types

Field Name in
Algorithm

SWIFT Processing

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

Global PAYplus | Message Types | Business Guide

Page 39

Message Types

c.

SWIFT Processing

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:

Global PAYplus | Message Types | Business Guide

Page 40

Message Types

SWIFT Processing

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

Global PAYplus | Message Types | Business Guide

Page 41

Message Types

SWIFT Processing

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

Global PAYplus | Message Types | Business Guide

Page 42

Message Types

SWIFT Processing

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 + / - Tolerance1, 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

Global PAYplus | Message Types | Business Guide

Page 43

Message Types

SWIFT Processing

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.

Global PAYplus | Message Types | Business Guide

Page 44

Message Types

SWIFT Processing

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.

Global PAYplus | Message Types | Business Guide

Page 45

Message Types

SWIFT Processing

-

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

Sender

Receiver

Dr Account

Cr Account

No

Local bank

Local bank

An asset account associated
The account mentioned
in field 25
with the BIC mentioned in field
56, or Default Account per
Payment Currency when field 56
is empty

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

210

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 perspecti ve Nostro B is
not a relevant party, therefore we do not derive, in this scenario, a credit account for the MT210.

Global PAYplus | Message Types | Business Guide

Page 46

Message Types

Reverse

Sender

SWIFT Processing

Receiver

Dr Account

Cr Account

210
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 1 st 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 1 st 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

Global PAYplus | Message Types | Business Guide

Page 47

Message Types

SWIFT Processing

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

Global PAYplus | Message Types | Business Guide

Page 48

Message Types

c.

SWIFT Processing

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
2.5.4.2.1

Nostro Account Position
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.

Global PAYplus | Message Types | Business Guide

Page 49

Message Types

SWIFT Processing

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.

Global PAYplus | Message Types | Business Guide

Page 50

Message Types

SWIFT Processing

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 List of Messages in Lower Half
Upper 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 List of Messages in Lower Half
Upper 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

Global PAYplus | Message Types | Business Guide

Page 51

Message Types

ISO 2022 Processing

Highlighted Message in List of Messages in Lower Half
Upper 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 All un-matched or possibly matched reverse MT210s with the same
class DD waiting for a
currency as the highlighted payment, and with an amount within a certain
match
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

Global PAYplus | Message Types | Business Guide

Page 52

Message Types

ISO 2022 Processing



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 53

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

Global PAYplus | Message Types | Business Guide

Page 54



Source Exif Data:
File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Language                        : en-GB
Tagged PDF                      : Yes
XMP Toolkit                     : Adobe XMP Core 5.2-c001 63.139439, 2010/09/27-13:37:26
Format                          : application/pdf
Creator                         : D+H
Description                     : Message Types
Title                           : Business Guide
Create Date                     : 2018:01:08 17:12:20+02:00
Creator Tool                    : Microsoft® Word 2016
Modify Date                     : 2018:01:08 17:12:30+02:00
Metadata Date                   : 2018:01:08 17:12:30+02:00
Producer                        : Microsoft® Word 2016
Document ID                     : uuid:21910a15-8038-487b-a20f-fb54f239f617
Instance ID                     : uuid:841135a0-d3d1-4b23-839e-85796da5caa6
Page Mode                       : UseOutlines
Page Count                      : 54
Author                          : D+H
Keywords                        : Global, PAYplus
Subject                         : Message Types
EXIF Metadata provided by EXIF.tools

Navigation menu