ISO20022 PaymentsInitiation MDR1 PDF

ISO 20022
Payments Initiation May 2013

Approved by the Payments SEG on 28 January 2013
Message Definition Report - Part 1
Edition 31 May 2013
Payments Initiation
Edition 31 May 2013
Table of contents
1.
Introduction ................................................................................................................3
1.1
Terms and definitions .................................................................................................. 3
1.2
Glossary...................................................................................................................... 3
1.3
Document Scope and Objectives ................................................................................. 4
1.4
References .................................................................................................................. 4
2.
Scope and Functionality ............................................................................................6

2.1
Background ................................................................................................................ 6
2.2
Scope .......................................................................................................................... 6
2.3
Groups of MessageDefinitions and Functionality ......................................................... 6
3.
BusinessRoles and Participants................................................................................7
4.
BusinessProcess Description....................................................................................9
4.1
BusinessProcess Diagram - Customer-to-bank payment order ...................................... 9
4.2
BusinessProcess Diagram - Customer-to-bank direct debit ......................................... 11
5.
Description of BusinessActivities ........................................................................... 13

5.1
BusinessActivity Customer-to-bank payment order .................................................. 13
5.2
BusinessActivity Customer-to-bank direct debit ........................................................ 19
6.
BusinessTransactions .............................................................................................20
6.1
Customer Credit Transfer Initiation BusinessTransaction ........................................... 20
6.2
Customer Credit Transfer Initiation in relay scenario BusinessTransaction................. 22
6.3
Customer Direct Debit Initiation and FIToFI Customer Direct Debit BusinessTransaction 25
6.4
Negative Customer and FIToFI Payment Status Report with Direct Debit BusinessTransaction
................................................................................................................................. 26
6.5
Positive Customer and FIToFI Payment Status Report with Direct Debit BusinessTransaction
................................................................................................................................. 29
6.6
Payment Return with Direct Debit BusinessTransaction............................................. 30
6.7
Customer Payment Reversal with Direct Debit BusinessTransaction .......................... 32
7.
Business examples ..................................................................................................35

7.1
CustomerCreditTransferInitiation - Business Example 1............................................. 35
7.2
CustomerPaymentStatusReport - Business Example 1 ................................................ 41
7.3
CustomerPaymentStatusReport - Business Example 2 ................................................ 42
7.4
CustomerPaymentReversal - Business Example 1 ...................................................... 45
7.5
CustomerDirectDebitInitiation - Business Example 1 ................................................. 48
8.
Revision Record .......................................................................................................54
Message Definition Report Part 1
Page 2
Payments Initiation
Edition 31 May 2013
1. Introduction
1.1 Terms and definitions
The following terms are reserved words defined in ISO 20022 Edition 2013 Part1. When used in this
document, they will be in italic and follow the UpperCamelCase notation.
Term
Definition
BusinessRole
functional role played by a business actor in a particular BusinessProcess or

BusinessTransaction
Participant
involvement of a BusinessRole in a BusinessTransaction
BusinessProcess
unrealized definition of the business activities undertaken by BusinessRoles

within a BusinessArea whereby each BusinessProcess fulfils one type of
business activity and whereby a BusinessProcess may include and extend
other BusinessProcesses
BusinessTransaction
particular solution that meets the communication requirements and the interaction
requirements of a particular BusinessProcess and BusinessArea
MessageDefinition
formal description of the structure of a message instance
1.2 Glossary
Acronyms
Acronym
Definition
ISTH
International Standards Team Harmonisation
CSTP
Corporate Straight Trough Processing Bank Group
CAG
Corporate Advisory Group
ISITC
International Securities Association for Institutional Trade Communication
IFX
Interactive Financial eXchange Forum
TWIST
Transaction Workflow Innovation Standards Team
CBI
Corporate Banking Interbancario
OAGi
Open Application Group
MDR
Message Definition Report
MCR
Message change request
SEG
Standards Evaluation Group
FI
Financial Institution
XML
eXtensible Mark-up Language
IBAN
International Bank Account Number
BIC
Business Identifier Code
ACH
Automated Clearing House
DD
Direct Debit
MRI
Mandate Related Information
Page 3
Payments Initiation
Edition 31 May 2013
Abbreviations
Abbreviation
Definition
e.g.
For example (exempli gratia)
etc.
Etcetera
i.e.
That is (id est)
1.3 Document Scope and Objectives

This document is the first part of the ISO Message Definition Report (MDR) that describes the
BusinessTransactions and underlying message set. For the sake of completeness, the document may
also describe BusinessActivities that are not in the scope of the project.
This document sets:
The BusinessProcess scope (business processes addressed or impacted by the project)
The BusinessRoles involved in these BusinessProcesses
The main objectives of this document are:
To explain what BusinessProcesses and BusinessActivities these MessageDefinitions have

addressed
To give a high level description of BusinessProcesses and the associated BusinessRoles
To document the BusinessTransactions and their Participants (sequence diagrams)
To list the MessageDefinitions
To list the Business samples
1.4 References
Document
Version
ISO 20022 Business Justification Customer to Bank

Payment Initiation
ISO 20022 Message Definition Report (MDR)
ISO 20022 Message Usage Guide (MUG)
2005
2006
2009
Date
Author
20-01-2005
SWIFT, IFX,
TWIST, OAGi
as part of the
IST
Harmonization
Team
14-09-2005
SWIFT, IFX,
TWIST, OAGi
as part of the
ISTH
01-10-2006
SWIFT, IFX,
TWIST, OAGi
as part of the
ISTH
08-01-2009
CSTP and the

ISTH team,
SWIFT, and
the SWIFT
Page 4
Payments Initiation
Edition 31 May 2013
Document
Version
Date
ISO 20022 Maintenance Change Request (MCR)

document (Payments Maintenance 2009)
2009
17-04-2009
SWIFT, ISTH,
ISITC
2009
30-09-2009
SWIFT, ISTH
13-06-2012
SWIFT, on
behalf of IFX,
SWIFT,
TWIST and
OAGi (ISTH),
the CBI
Consortium
and the
French
SWIFT Users
Group

document (Payments Maintenance 2011/2012)
2012
Author
CAG
SWIFT, on

document (Payments Maintenance 2012/2013)
2012
2013
2013
14-06-2012
behalf of IFX,
TWIST, OAGi
and SWIFT
28-01-2013
SWIFT, on
behalf of IFX,
SWIFT,
TWIST and
OAGi (ISTH).
31-05-2013
SWIFT, on
behalf of IFX,
SWIFT,
TWIST and
OAGi (ISTH).
Page 5
Payments Initiation
Edition 31 May 2013
2. Scope and Functionality

2.1 Background
This Message Definition Report covers a set of 4 ISO 20022 MessageDefinitions developed by SWIFT in
close collaboration with IFX, TWIST, OAGi and approved by the Payments Standards Evaluation Group
(SEG) on 28 January. These messages are specifically designed to support the customer-to-bank
information flow.
2.2 Scope
Set of messages exchanged between a debtor and its bank or between a creditor and its bank to initiate,
collect, manage and monitor payments.
The Customer Credit Transfer Initiation and Customer Direct Debit Initiation messages described in this
document can be used for initiating either multiple payment orders or single transfers.
2.3 Groups of MessageDefinitions and Functionality
Instruction messages
o The CustomerCreditTransferInitiation message: used to request movement of funds
from the debtor account to a creditor;
o The CustomerDirectDebitInitiation message: used to request the collection(s) of funds
from one or more debtor's accounts for a creditor.
Related messages
o The CustomerPaymentReversal message: used to reverse a payment previously
executed;
o The CustomerPaymentStatusReport message: used to inform on the positive or negative
status of an instruction (either single or file) and to report on a pending instruction.
Page 6
Payments Initiation
Edition 31 May 2013
3. BusinessRoles and Participants

A BusinessRole represents an entity (or a class of entities) of the real world, physical or legal, a person,
a group of persons, a corporation. Examples of BusinessRoles: Financial Institution, ACH, CSD.
A Participant is a functional role performed by a BusinessRole in a particular BusinessProcess or
BusinessTransaction: for example the user of a system, debtor, creditor, investor etc.
The relationship between BusinessRoles and Participants is many-to-many. One BusinessRole (that is, a
person) can be involved as different Participants at different moments in time or at the same time: "user",
"debtor, "creditor", "investor", etc. Different BusinessRoles can be involved as the same Participant.
In the context of Payments Initiation, the high-level BusinessRoles and typical Participants can be
represented as follows.
Participants and BusinessRoles definitions

Description
Definition
Participants
Debtor
The party that owes an amount of money to the (ultimate) creditor. In

the context of the payment model, the debtor is also the debit account
owner.
Creditor
Party to which an amount of money is due. In the context of the

payment model, the creditor is also the credit account owner.
UltimateDebtor
The ultimate party that owes an amount of money to the (ultimate)

creditor.
UltimateCreditor
The ultimate party to which an amount of money is due.
DebtorAgent
Financial Institution servicing an account for the debtor.
CreditorAgent
Financial Institution servicing an account for the creditor.
ForwardingAgent
Financial institution that receives the instruction from the initiating party
and forwards it to the next agent in the payment chain for execution.
InitiatingParty
Party initiating the payment to an agent. In the payment context, this

can either be the debtor (in a credit transfer), the creditor (in a direct
debit), or a party that initiates the payment on behalf of the debtor or
creditor.
Account Owner
Party that legally owns the account.
Account Servicer
Party that manages the account on behalf of the account owner, that is
manages the registration and booking of entries on the account,
calculates balances on the account and provides information about the
account.
PaymentClearingAgent
(=InstructingAgent)
An agent that instructs the next party in the payment chain to carry out
the payment/instruction.
PaymentSettlementAgent
An agent that executes the instruction upon the request of the previous
party in the chain (either an agreement party, or a clearing agent).
(=InstructedAgent)
IntermediaryAgent
Financial Institution that receives a financing request from the Financing

Requestor and forwards it to the First Agent for execution.
BusinessRoles
Organisation established primarily to provide financial services.
Clearing System
Specifies the system which plays a role in the clearing process.
Page 7
Payments Initiation
Edition 31 May 2013
Participants and BusinessRoles definitions

Description
Definition
Party
Entity involved in a payment.
BusinessRoles/Participants Matrix Table

Participants
Clearing System
Party
BusinessRoles
Debtor
Creditor
UltimateDebtor
UltimateCreditor
DebtorAgent
CreditorAgent
ForwardingAgent
InitiatingParty
Account Owner
Account Servicer
PaymentClearingAgent
PaymentSettlementAgent
IntermediaryAgent
Page 8
Payments Initiation
Edition 31 May 2013
4. BusinessProcess Description
4.1 BusinessProcess Diagram - Customer-to-bank payment order
This diagram pictures the high level end-to-end payments BusinessProcesses. The first drill down
includes the customer-to-bank payment, which is covered by this document. The aim of the below is to
describe the high-level scope of the project, not to be exhaustive.
Process Customer-to-bank payment
Definition: This business process bundles all underlying sub-processes which are all related to
the initiation and handling of customer-to-bank payments. The sub-processes are:
o order customer-to-bank payment
o accept customer-to-bank payment
o clear customer-to-bank payment
Page 9
Payments Initiation
Edition 31 May 2013
and settle customer-to-bank payment.
Order customer-to-bank payment
Definition: an initiating party orders to its financial institution (debtor agent or forwarding agent) a
payment related and possibly referring to the underlying business transactions (for example,
invoices).
Trigger: decision has been made to make a payment (either by a person or a system)
Pre-condition: the required (identifying) information is available to make a payment.
Post-condition: The initiation party sends a CustomerCreditTransferInitiation message to the
forwarding agent or debtor agent.
Authorise customer-to-bank payment
Definition: the authorisation of a payment order by the initiating party. (An authorisation may be
implicit if the system where the payment is generated has been approved to generate payments,
as the preceding procedures are deemed satisfactory secure. The system will then generate a
digital signature without manual intervention. An authorisation may be explicit, if procedures
require human approval. The representation of this approval will be included in the payment
order or sent to the forwarding or debtor agent as a separate message.)
Trigger: a payment order has been created.
Pre-condition: the order payment process has completed and waits for authorisation.
Post-condition: the payment order is authorised.
Accept customer-to-bank payment
Definition: The payment acceptation includes the checking of the authorisation, the validation of
the payment and the process risk assessment.
Trigger: receipt of a payment order.
Post-condition: the payment order has been accepted or rejected.
Check Authorisation customer-to-bank payment
Definition: The forwarding or debtor agent checks if initiating party is allowed/entitled to do so as

included in the authorisation specifications of the customer profile and the type of payment is in
scope.
Note: Authorisation procedures are in some countries required for legal reasons
The result of these authorisation procedures can, depending on the authorisation scenario
defined, be included in the payment initiation order (e.g. one or more signatures included in the
payment initiation order), or can result in a dissociated authorisation message, sent by another
party than the initiating party, which is referring to the payment initiation message.
Trigger: established authorisation procedures.
Post-condition: the payment will be accepted or rejected for validation and, when applicable, risk
assessment.
Validate customer-to-bank payment
Definition: syntactical check in order to process the payment further.

Pre-condition: the agent has received the payment order and performed the necessary
authorisation checks. Validation procedures have been established.
Trigger: receipt of payment order, positive authorisation check.
Post-condition: the payment will be accepted for risk assessment, if necessary, or is executable.
Assess customer-to-bank payment risk
Definition: necessary risk checks in order to execute and process the payment further. It can be
'assess static risk' (e.g. checking of embargo) and 'assess dynamic risk' (check sufficient cash on
account, cover received,).
Pre-condition: the payment has been validated and risk criteria have been established.
Trigger: receipt of payment order, positive authorisation and validation check.
Post-condition: the payment or is executable (all information is there to process the payment and
the payment risk assessment had been checked).
Page 10
Payments Initiation
Edition 31 May 2013
Generate regulatory reporting information
Definition: information from the payment transaction necessary to meet regulatory reporting
requirements (for example, balance of payments reporting, reporting on money-laundering
issues,)
Pre-condition: there are regulatory reporting requirements.
Trigger: the payment meets regulatory reporting criteria.
Post-condition: information for the regulatory reporting has been extracted based in the
information in the payment.
Clear customer-to-bank payment
Definition: The agent remits the payment and prepares the information for the next agent in the
interbank chain by sorting it and release it for onward interbank payment processing.
Pre-condition: the payment is accepted, the next credit party is not the creditor and the next
clearing agent is determined.
Trigger: execution date.
Post-condition: onward interbank payment processing.
Settle customer-to-bank payment
Definition: credit transfer between the debit party and the credit party
Pre-condition: instructed payment is executable (all information is there to process the payment
and the payment validity has been checked)
Trigger: execution date.
Post-condition: transfer of ownership is performed between the debit party and the credit party.
4.2 BusinessProcess Diagram - Customer-to-bank direct debit

This diagram pictures the high level Direct Debit end-to-end payments BusinessProcesses. The first drill
down includes the customer-to-bank payment, which is covered by this document. The aim of the below
is to describe the high-level scope of the project, not to be exhaustive.
Initiate collection of Direct Debit
Definition: the Creditor will create the first/one-off Direct Debit instruction and send it to its bank.
This first/one-off Direct Debit will differ from subsequent (recurrent) Direct Debit transactions:
The first/one-off Direct Debit instruction may be sent a number of days (as defined in the operating rules)
in advance of the settlement date.
Page 11
Payments Initiation
Edition 31 May 2013
In addition to the regular debiting information, which may include the unique mandate reference and the
Creditor identification, the first/one-off debit instruction may also include information that identifies it as a
first Direct Debit under a new mandate or as a one-off transaction
Trigger: Initiation of the collection

Pre-condition: Consensus to use Direct Debit as payment method and Debtor authorisation to be
debited by the Creditor, Notification of the Debtor
Post-condition: Initiated collection of Direct Debit
Process reject
Definition: Reconciles reject with the original Direct Debit instructions and identifies the reason
for rejection. If the reject results from a formatting error, correct the data and resubmit for
processing
Trigger: Reconciliation of the Reject
Pre-condition: Reject received
Post-condition: Reconciled reject
Process return/request for refund
Definition: Returns are individual debits that have reached the Debtors Agent and have been
settled at the inter-bank level, but the Debtors Agent is then unable to make the collection for
one of a number of reasons e.g. account closed, no funds, customer dead, etc.
The Debtor has the unconditional right during "n" days after a debit to instruct its bank to revoke
the debit. Following that instruction the Debtor's account is credited by his bank and the debit is
returned electronically through the clearing process to the Creditors Agent.
Trigger: Return of a Direct Debit / Request for refund
Pre-condition: Settled Direct Debit instruction subject for return / refund
Post-condition: Returned Direct Debit instruction / Requested Refund
Process reversal
Definition: Creditor identifies the original Direct Debit instruction (or a file of Direct Debit
instructions) and generates an offsetting transaction in favor of the Debtor under quotation of the
reversal reason.
Trigger: Reversal of the Direct Debit Instruction
Pre-condition: Settled Direct Debit instruction subject to reversal (collected in error)
Post-condition: Reversed Direct Debit Instruction
Page 12
Payments Initiation
Edition 31 May 2013
5. Description of BusinessActivities
This section presents the different BusinessActivities within each BusinessProcess. BusinessActivities of
a process are described in swim lane diagrams and are referred in this document as activity diagrams.
The development of an activity diagram is part of the ISO 20022 modelling process and allows capturing
the requirements.
The activity diagram provides a zoom-in on the BusinessActivities taking place during each of the
BusinessProcesses described in Section 4. It also shows the BusinessActivities that are triggered when
another BusinessAtivity has a negative result.
What is the activity diagram about?
It is a diagram representing the common lifecycle of a BusinessProcess

A start point l shows where the lifecycle of the business process commences and the end
points show
where the lifecycle may possibly end
A lozenge
means a that a choice between several actions can be made
A bar
means a that several actions are initiated in parallel
The flow of activities between the involved Participants (parties)
BusinessActivities may result in different actions, that is, information is conveyed from one party
to another party.
Both in scope and out of scope activities are included, with a different level of details. There are no
information requirements for out of scope activities, except that they should be clearly identified in the
diagram.
5.1 BusinessActivity Customer-to-bank payment order

In the customer-to-bank payment order(s), multiple participants can be present.
Simple scenario:
Complex scenario:
Page 13
Payments Initiation
Edition 31 May 2013
Descriptions of the BusinessActivities

Initiator
(1) Prepare, authorise and send payment order(s)
Initiating Party/Debtor
An initiating party collects the information necessary to initiate a payment to

the forwarding or Debtor Agent.
Depending whether the initiating party is a corporate or an individual, the
business information needed in the business process is slightly different.
Receive payment order and check authentication
The forwarding agent, if present, and Debtor agent receive the payment
orders from the previous party in the chain.
Technical Validation (3.1), risk assessment (3.2), apply business rules (3.3)
and prepare payment orders for onward transmission (3.4).
Forwarding Agent /
Debtor Agent
Forwarding Agent /
Debtor Agent
Necessary checks before processing the payment order further include, for
Page 14
Payments Initiation
Edition 31 May 2013

Initiator
example, syntactical validation.
The Debtor agent undertakes the necessary risk checks when the execution
date is reached, in order to further process the payment. Examples of
dynamic risk assessment are: is sufficient cash available, has cover been
received, etc.
Examples of static risk assessment are: check limits, embargo, money
laundering information, etc.
The forwarding agent (if any) or Debtor agent will check business rules that
he has logged for the initiating party sending the file. These business rules
include information about the customer's profile : the type of transactions the
customer is allowed to send, the authorisation procedures set up between
customer and receiving agent, etc.
The forwarding agent rebuilds the payment order by
-subtracting the failed/invalid individual payment instructions from the
payment orders he received
-bulking, if relevant, of several payment orders coming from different initiating
parties or agents acting as forwarding agents. The merge criteria are defined
by the bank
(4) Receive (and forward) Status Report
The initiating party can receive from the forwarding and/or debtor agent
different status reports for the payment order.
Initiating Party/ Debtor

Agent / Forwarding
Agent
The payment status report can be produced at different stages of the

processing and may have a different business value (depending on the
checks performed: payment authentication, syntax validation, risk
assessment, etc.).
In the case of a relay scenario, there may be a duplication of payment status
reports when e.g. a first risk analysis report is produced by the agent acting
as a forwarding agent and a second risk analysis report be produced by the
Debtor agent (acting as the executing agent in that case).
Payment status report can only concern the rejected items for a given
payment order group or encompass both positive and negative (i.e.
rejections) acknowledgement for the items in the payment order group. It
may optionally report on pre-agreed repair action taken by the bank.
At any stage, the payment status report expresses whether the payment
order is accepted for further processing (i.e. valid from a syntax, business
content, risk analysis point of view) or rejected and the reason for rejection or
whether the payment has been repaired and how.
Depending on agreement between the initiating party and the Debtor agent
(or forwarding agent in relay scenario), the payment orders may be rejected
as a whole or partially. The rejection criteria can be fixed as a percentage or
an absolute number of individual rejected orders or other agreed criteria.
Consequently, in case of reject of all the payment orders, a global status can
be returned with the global reason.
Note: in case of a relay scenario, where the Debtor agent generates the
status report, it will first be the forwarding agent who receives the status
Page 15
Payments Initiation
Edition 31 May 2013

Initiator
report. The forwarding agent will then forward the status report to the
initiating party.
Note: 'send negative status report' and 'send positive status reports' are
subsets of 'send status report'. A negative status report will only include
rejected items; a positive status report will include accepted items and
repaired items. A 'generic' status report can include a combination of
negative and positive status reports.
When the initiating party receives a negative status report (containing
rejected items), based on the negative status message (reject) from the first
or forwarding agent, the initiating party analyses the reason for rejection,
corrects the information causing this reject and reverses the payment: he
removes the payment from remittance in transit and resets the underlying
invoices to payable again.
Confirm acceptance (5.1) and send (5.2), receive and/or forward (5.3)
acceptance acknowledgement
Debtor Agent /
Forwarding Agent
This acceptance acknowledgement signifies that the payment order (subject

to prior information received through the various payment status reports) will
be processed by the Debtor agent and will trigger accounting entries on the
debtor/initiating party account maintained at the Debtor agent.
(6) Reconcile and track payment
Initiating Party / Debtor
The initiating party will reconcile events coming from its information system
(e.g. account receivables) with external information feeds (e.g. debit advices,
account statement, acceptance notification).
This process aims at matching both internal and external views and
identifying items for which further attention is required.
The reconciliation either ends the financial leg of a transaction (from payment
inception to payment completion confirmation) when positive or leads to
investigations or claims when negative.
(7) Debit account and Credit Internal account
Debtor Agent
The Debtor agent debits the account stipulated as being the debit account in
the payment order.
This includes currency conversion and charges if needed.
The Debtor agent, after having successfully debited the debtor's account,
credits internal accounts in order to transfer the provision necessary to
process the payment order further.
(7.1) Send, receive and/or forward Debit Advice

The debit advice, prepared by the Debtor Agent, notifies the initiating party
that the settlement has been performed i.e. that the debit entry has been
passed on the account of the debtor/initiating party. The initiating party uses
it for the reconciliation of entries vis--vis payment orders received/remitted.
The initiating party receives a notification from the Debtor agent, (possibly
through the forwarding agent - if any), that the debit entry has been passed
Debtor Agent /
Forwarding Agent
Page 16
Payments Initiation
Edition 31 May 2013

Initiator
on the account of the debtor (which may or may not be equal to the initiating
party).
This debit advice will be further used for the reconciliation of entries vis--vis
payment orders received/remitted.
The forwarding agent forwards to the initiating party a notification received
from the Debtor agent that the debit entry has been passed on the account of
the debtor/initiating party.
This debit advice will be further used by the initiating party for the
reconciliation of entries vis--vis payment orders received/remitted.
(8) Internal bookkeeping

The Debtor agent debits the internal account where the provision for further
processing of the payment order has been blocked. The Creditor Agent
credits the creditor's account in its books.
(9) Print Cheques

If the initiating party has asked the Debtor agent to issue a cheque to pay the
creditor, the Debtor agent or Creditor Agent will print a cheque.
(10) Rebuild payment order(s)
Debtor Agent / Creditor

Agent
Debtor Agent / Creditor

Agent
Debtor Agent
The Debtor agent rebuilds the payment order by

-subtracting the failed/invalid individual payment instructions from the
-subtracting, if relevant, the 'on us' individual payment instructions from the
-merging, if relevant, of several payment orders coming from different
initiating parties or agents acting as forwarding agents. The merge criteria
are defined by the bank.
-re-building a consistent remittance
Send (11) /receive and forward (11.1) execution status

The initiating party optionally receives an execution status report from the
Debtor agent (possibly through the forwarding agent - if any).
Debtor Agent /
Forwarding Agent
The forwarding agent forwards to the initiating party a notification received

from the Debtor agent that the payment order file has been executed.
Depending on the payment method requested and depending on the routing
information contained in the payment order:
-
the creditor(s) has/have been credited in the books of the

Debtor agent (for 'on-us' payments)
the Debtor agent has printed and sent cheques
the Debtor agent has sent off the payment orders which need
to be further routed in the payment chain (for 'not on-us'
payments)
Note: if the creditor has an account in the books of the Debtor agent (which is
same as Creditor Agent then), this execution status is a 'final' execution
status (that is, the creditor has been credited by his agent).
Page 17
Payments Initiation
Edition 31 May 2013

Initiator
In the other cases ('receive cheques'/and when the creditor has an account
at a different agent than the Debtor agent), the execution status is not yet
'final' - that is, the execution status does not include the actual confirmation
of credit of the creditor by his agent - or cashing of cheque by the beneficiary
Page 18
Payments Initiation
Edition 31 May 2013
5.2 BusinessActivity Customer-to-bank direct debit
Return direct debit:
Request refund direct debit:
Page 19
Payments Initiation
Edition 31 May 2013
6. BusinessTransactions
This section describes the message flows based on the activity diagrams documented above. It shows
the typical exchanges of messages in the context of a BusinessTransaction.
6.1 Customer Credit Transfer Initiation BusinessTransaction

The CustomerCreditTransferInitiation message is sent from the Initiating Party to the Debtor Agent.
Depending on the service level agreed between the Debtor Agent and the Initiating Party, the Debtor
Agent may send a CustomerPaymentStatusReport message to inform the Initiating Party of the status of
the initiation.
A number of additional message flows have been included to illustrate the complete end-to-end
execution of the
CustomerCreditTransferInitiation. However, these messages are out of scope. These message flows are:
Account information from Debtor Agent to Initiating Party: Depending on the service level
agreed, the Debtor Agent may provide the Initiating Party with a
BankToCustomerDebitCreditNotification ('notification') and/or
BankToCustomerAccountReport/BankToCustomerStatement ('statement') once the payment has
been executed and the debit entry has been posted to the Debtor account. The logical,
chronological sequence for sending these messages is defined by the bank implementing and
offering these services.
Interbank clearing and settlement between Debtor Agent and Creditor Agent: Depending on the
interbank clearing and settlement method chosen, a number of messages may be exchanged
between the agent parties in the payment chain.
Account information from Creditor Agent to Creditor: Depending on the service level agreed, the
Creditor Agent may provide the Creditor with a BankToCustomerDebitCreditNotification
('notification') and/or BankToCustomerAccountReport/BankToCustomerStatement ('statement')
once the payment has been posted to the Creditor account. The logical, chronological sequence
for sending these messages is defined by the bank implementing and offering these services.
The scenarios below illustrate the different customer roles that can be played on the initiating side of the
credit transfer initiation, and on the receiving side of the cash transfer.
On the initiating side, up to three customer roles can be specified: the Initiating Party, i.e., the party
sending the message, the Debtor, i.e. the debit account owner, and the Ultimate Debtor, i.e., the party
that owes the cash to the Creditor as a result of receipt of goods or services.
These three roles can be played by one and the same actor, or they can be played by different actors.
The CustomerCreditTransferInitiation message allows inclusion of the three different roles on the
initiating side.
On the receiving side, up to two customer roles can be specified: the Creditor, i.e., the credit account
owner, and the Ultimate Creditor, i.e., the party that is the ultimate beneficiary of the cash transfer. These
two roles can be played by one and the same actor, or they can be played by different actors.
The CustomerCreditTransferInitiation message allows inclusion of the two different roles on the receiving
side.
Scenario A:
One actor playing roles of Initiating Party, Debtor and Ultimate Debtor and one actor playing roles of
Creditor and Ultimate Creditor
Page 20
Payments Initiation
Edition 31 May 2013
The message is sent by an Initiating Party to the Debtor Agent. The actor playing the role of Initiating
Party is the same as the actor playing the role of Debtor and Ultimate Debtor. The actor playing the role
of Creditor is the same as the actor playing the role of Ultimate Creditor.
Scenario B:
One actor playing roles of Initiating Party and Debtor, different actor for the role of Ultimate Debtor
Page 21
Payments Initiation
Edition 31 May 2013
Party is the same as the actor playing the role of Debtor, but the role of the Ultimate Debtor is played by
a different actor.
Scenario C:
Three different actors playing the roles of Initiating Party, Debtor and Ultimate Debtor
Party is different from the actor playing the role of Debtor. The role of the Ultimate Debtor is played by
yet another actor.
6.2 Customer Credit Transfer Initiation in relay scenario BusinessTransaction

The CustomerCreditTransferInitiation message is sent from the Initiating Party to the Forwarding Agent.
Depending on the service level agreed between the Forwarding Agent and the Initiating Party, the
Forwarding Agent may send a CustomerPaymentStatusReport message to inform the Initiating Party of
the status of the initiation.
After performing a series of checks, the Forwarding Agent will forward the
CustomerCreditTransferInitiation message to the relevant Debtor Agent, i.e., the agent that will debit the
Debtor account.
A relay scenario always requires service level agreements between all parties involved, in which
obligations and responsibilities for each party are stipulated.
A number of additional message flows have been included to illustrate the complete end-to-end
execution of the payment initiation. However, these messages are out of scope.
The below scenarios show the different customer roles that can be played on the initiating side of the
credit transfer initiation, and on the receiving side of the cash transfer.
On the initiating side, up to three customer roles can be specified: the Initiating Party, i.e., the party
sending the message, the Debtor, i.e., the debit account owner, and the Ultimate Debtor, i.e., the party
that owes the cash to the Creditor, as a result of receipt of goods or services.
These three roles can be played by one and the same actor, or they can be played by different actors.
The
CustomerCreditTransferInitiation message allows inclusion of the three different roles on the initiating
side.
Page 22
Payments Initiation
Edition 31 May 2013
On the receiving side, up to two customer roles can be specified: the Creditor, i.e., the credit account
owner, and the Ultimate Creditor, i.e., the party that is the ultimate beneficiary of the cash transfer. These
two roles can be played by one and the same actor, or they can be played by different actors. The
CustomerCreditTransferInitiation message allows inclusion of the two different roles on the receiving
side.
Scenario A:
One actor playing roles of Initiating Party, Debtor and Ultimate Debtor
The message is sent by an Initiating Party to the Forwarding Agent. The actor playing the role of Initiating
Party is the same as the actor playing the role of Debtor and Ultimate Debtor. This illustrates the
scenario in which a company owns accounts abroad and uses a concentrator bank to initiate all its
payments. The company plays the role of Debtor, Ultimate Debtor and Initiating Party and asks the
Forwarding Agent to request the execution of the payment at the Debtor Agent, i.e., the account servicer
of the Debtor. After performing a series of checks, the Forwarding Agent will forward the message to the
Debtor Agent.
Scenario B:
One actor playing roles of Initiating Party and Debtor, different actor for the role of Ultimate Debtor
Page 23
Payments Initiation
Edition 31 May 2013
Party is the same as the actor playing the role of Debtor, but the role of the Ultimate Debtor is played by
a different actor. This illustrates the scenario in which, for example, a company's head office
concentrates all payments from its subsidiaries. The head office plays the role of Debtor and Initiating
Party, whilst the subsidiaries play the role of originating parties, in this case Ultimate Debtor. After
performing a series of checks, the Forwarding Agent will forward the message to the Debtor agent.
Scenario C:
One actor playing role of Initiating Party and Ultimate Debtor, different actor for role of Debtor
Party is the same as the actor playing the role of Ultimate Debtor, but the role of the Debtor is played by
a different actor. This illustrates the scenario in which, for example, a head office initiates the payment,
Page 24
Payments Initiation
Edition 31 May 2013
but has agreed with its subsidiary abroad to use the account of the subsidiary for certain payments. After
performing a series of checks, the Forwarding Agent will forward the message to the Debtor Agent.
6.3 Customer Direct Debit Initiation and FIToFI Customer Direct Debit
BusinessTransaction
A Direct Debit is a request for payment of an amount to be collected from a party bank account (the
Debtor) by an originator (the Creditor). The amounts and dates of collections may vary.
Direct Debits result in cash transfers between Debtors and Creditors through infrastructures or
correspondent banks. They may be exchanged as single instructions but are traditionally grouped
following some common characteristics and, for convenience or efficiency reasons, exchanged in a batch
mode.
Direct Debits are processed in different ways from country to country, especially regarding the handling
of the mandate (when it exists) given by the Debtor to the Creditor.
The CustomerDirectDebitInitiation message is sent by the Initiating Party (Creditor) to the Forwarding
Agent or Creditor Agent. It is used to request single or bulk collection(s) of cash from one or various
Debtor account(s) to a Creditor.
The FIToFICustomerDirectDebit message is sent by a Financial Institution to another Financial
Institution, directly or through a Clearing System. It is used to clear Direct Debit instructions, initiated by
non-financial institution customers.
The original mandate between the Debtor and the Creditor and the mandate management itself are
identified as being out of scope and are therefore not included in the diagram. Some information on
possible mandate management information flow is available below.
The mandate is the authorisation/expression of consent given by the Debtor, allowing a specified
Creditor to originate Direct Debit instructions to debit a specified Debtor account in accordance with the
relevant Direct Debit Scheme Rules and, if applicable, the mandate details.
A valid/authorised mandate represents the Debtor agreement:
to authorise the Creditor to issue Direct Debit instruction(s) to the Debtor account, and;
to instruct the Debtor Agent to act upon the Creditor Direct Debit instruction.
Note: in some cases, the Debtor Agent is unaware of the Mandate and simply acts upon the Direct Debit
instruction.
A mandate can be an electronic mandate or a mandate in paper form. In case of a paper mandate the
Creditor dematerialises the mandate upon the mandate presentation in paper form. Dematerialised
mandate data are referred to as the Mandate Related Information (MRI) only and are not to be
considered as the mandate document. The original mandate remains subject for archiving and reference
for any legal matter.
Page 25
Payments Initiation
Edition 31 May 2013
Prior to the sending of a Direct Debit instruction, the Creditor may notify the Debtor of the amount and
date on which the Direct Debit instruction will be presented to the Debtor Agent for debit. This notification
may be sent together with or separately from other commercial documents (for example, an invoice).
There are two types of pre-notifications:
Schedule of payments for a number of subsequent Direct Debits for an agreed period of time.
Individual advises of a Direct Debit subject for collection on a specified value date only. In case
of recurrent
Direct Debit this requires an update for each individual recurrent Direct Debit prior to its collection.
The Debtor will reconcile the pre-notification with the signed/authorised mandate and where relevant
other records (such as account payable items, contract details or subscription agreement). The Debtor
ensures the account is covered with subject amount.
In scope: The Creditor sends the CustomerDirectDebitInitiation message to its Agent (the Creditor
Agent), together with the Mandate Related Information when requested by the scheme.
In scope: The Creditor Agent sends an FIToFICustomerDirectDebit message to the Clearing and
Settlement Agent, in line with the clearing cycle. The Mandate Related Information (MRI) is also
transported, when requested by the scheme.
In scope: The Clearing and Settlement Agent sends the FIToFICustomerDirectDebit message, together
with the
Mandate Related Information (MRI), when requested by the scheme, to the Debtor Agent.
Out of scope: Potentially, the Debtor Agent could forward the Direct Debit instruction (simplified version)
to the debtor (for example in case pre-notifications are not used in a Scheme).
Out of scope: In case the Clearing and Settlement Agent are two parties the Clearing Agent prepares
and sends the payment information for the Settlement Agent (in accordance with the agreed and
published settlement cycle). The process includes the calculation of the settlement positions and
transmission of the files to the Settlement Agent.
The information provided includes the net position to be debited, the party to be debited, the net position
to be credited, the party to be credited and the value date.
The Clearing Agent prepares and sends the payment information for the Settlement Agent (in
accordance with the agreed and published settlement cycle). The process includes the calculation of the
settlement positions and transmission of the files to the Settlement Agent.
The information provided includes the net position to be debited, the party to be debited, the net position
to be credited, the party to be credited and the value date.
The settlement is executed by the Settlement Agent, in accordance with the settlement cycle, based on
the settlement report provided by the Clearing Agent. The Settlement Agent performs the transfer of
funds from the Debtor Agent to the Creditor Agent.
Out of scope: Reporting (BankToCustomerDebitCreditNotification message ('notification') and/or
BankToCustomerAccountReport/ BankToCustomerStatement message ('statement')) to the Debtors and
Creditors. Timing may vary depending on market practices and value added services provided by some
Agents, that is, before or after settlement.
6.4 Negative Customer and FIToFI Payment Status Report with Direct Debit
BusinessTransaction
The negative CustomerPaymentStatusReport message (single or grouped) or
FItoFIPaymentStatusReport message (single or grouped) is sent by the receiver of an instruction to
inform the sender of the instruction about the negative processability of the instruction.
The negative CustomerPaymentStatusReport message FIToFIPaymentStatusReport message used to
reject a direct debit instruction, is to be sent before settlement. After settlement, the correct message to
be used is the PaymentReturn message.
Page 26
Payments Initiation
Edition 31 May 2013
Scenario A:
A negative CustomerPaymentStatusReport message initiated by the Creditor Agent to reject a
CustomerDirectDebitInitiation message.
The Creditor sends the CustomerDirectDebitInitiation message to its Agent (the Creditor Agent).
The Creditor Agent sends a negative CustomerPaymentStatusReport message to the Creditor to inform
him about the non processability of the CustomerDirectDebitInitiation instruction, for instance due to
missing information.
Scenario B:
A negative FIToFIPaymentStatusReport message initiated by the Clearing and Settlement Agent to
reject an FIToFICustomerDirectDebit message.
* Information: If the Creditor Agent books after collection (i.e. cycle is 3 days) then the
CustomerPaymentStatusReport message is to be used. If the Creditor Agent books immediately and the
instruction is rejected in the interbank leg, then the Creditor needs to be informed of a payment return
The Creditor Agent confirms the processability of the CustomerDirectDebitInitiation instruction by
sending a positive
CustomerPaymentStatusReport message to the Creditor.
The Creditor Agent sends an FIToFICustomerDirectDebit message to the Clearing and Settlement
Agent, in line with the clearing cycle. The Mandate Related Information (MRI) is also transported, when
applicable.
Page 27
Payments Initiation
Edition 31 May 2013
If information is missing and interbank settlement has not taken place yet, the Clearing and Settlement
Agent informs the Creditor Agent about the non processability of the FIToFICustomerDirectDebit
instruction. The Creditor Agent may inform (but not necessarily) his customer, the Creditor, about the
negative processing of the CustomerDirectDebitInitiation instruction by using a negative
CustomerPaymentStatusReport message, a BankToCustomerDebitCreditNotification message
('notification') or through a BankToCustomerAccountReport and/or BankToCustomerStatement
message.
Note: Before sending a negative CustomerPaymentStatusReport message to its customer, it is assumed
that the Creditor Agent will try to correct the CustomerDirectDebitInitiation message information and resubmit an FIToFICustomerDirectDebit message to the Clearing and Settlement Agent. In this case the
Creditor will not be involved.
Scenario C:
Negative FIToFIPaymentStatusReport message initiated by the Debtor Agent to Reject the
FIToFICustomerDirectDebit message.
* Information: If the Creditor Agent books after collection (i.e. cycle is 3 days) then the
CustomerPaymentStatusReport message is to be used. If the Creditor Agent books immediately and the
instruction is rejected in the interbank leg, then the Creditor needs to be informed of a payment return.
The Creditor sends a CustomerDirectDebitInitiation message to its Agent (the Creditor Agent).
The Creditor Agent confirms the processability of the CustomerDirectDebitInitiation message by sending
a positive
applicable.
The Clearing and Settlement Agent confirms the processability of the FIToFICustomerDirectDebit
message by sending a positive FIToFIPaymentStatusReport message to the Creditor Agent.
Page 28
Payments Initiation
Edition 31 May 2013
The Clearing and Settlement Agent sends an FIToFICustomerDirectDebit message, together with
potentially the
Mandate Related Reference (MRI) to the Debtor Agent immediately for information purposes only.
If settlement has not yet taken place, the Debtor Agent may send a negative
FIToFIPaymentStatusReport message to the Clearing and Settlement Agent, to inform him about the
rejection of the FIToFICustomerDirectDebitinstruction. This negative FIToFIPaymentStatusReport
message may subsequently be forwarded to the Creditor Agent. The Creditor Agent may inform (but not
necessarily) his customer, the Creditor, about the negative processing of the
CustomerDirectDebitInitiation instruction by using a CustomerPaymentStatusReport message, a
BankToCustomerDebitCreditNotification message ('notification') or through a
BankToCustomerAccountReport and/or BankToCustomerStatement message ('statement').
6.5 Positive Customer and FIToFI Payment Status Report with Direct Debit
BusinessTransaction
The positive CustomerPaymentStatusReport message (single or grouped) and
FIToFIPaymentStatusReport message (single or grouped) is sent by the receiver of an instruction to
inform the receiver that the instruction received is processable.
A positive CustomerPaymentStatusReport message or FIToFIPaymentStatusReport message can also
be used to confirm the processability of a PaymentReturn message (in case of FIToFI) or a
PaymentReversal message.
The positive CustomerPaymentStatusReport message and FIToFIPaymentStatusReport message are
also meant to be generic to ensure re-usability with other Payments Instruments.
The CustomerPaymentStatusReport and FIToFIPaymentStatusReport messages are exchanged, point
to point between two parties, optionally and as per bilateral agreements and may be complemented by a
BankToCustomerDebitCreditNotification message ('notification') and/or BankToCustomerAccountReport/
BankToCustomerStatement message ('statement').
Scenario: Use of the CustomerPaymentStatusReport message and FIToFIPaymentStatusReport
message to confirm the processability of a CustomerDirectDebitInitiation instruction, followed by an
FIToFICustomerDirectDebit message.
In scope: The Creditor sends the CustomerDirectDebitInitiation message to its Agent (the Creditor
Agent).
Page 29
Payments Initiation
Edition 31 May 2013
In scope: The Creditor Agent confirms the processability of the CustomerDirectDebitInitiation instruction
by sending a positive CustomerPaymentStatusReport message to the Creditor.
In scope: The Creditor Agent sends an FIToFICustomerDirectDebit message to the Clearing and
Settlement Agent, in line with the clearing cycle. The Mandate Related Information (MRI) is also
transported, when applicable.
In scope: The Clearing and Settlement Agent confirms the processability of the
FIToFICustomerDirectDebit instruction by sending a positive FIToFIPaymentStatusReport message to
the Creditor Agent.
In scope: The Clearing and Settlement Agent sends an FIToFICustomerDirectDebit message, together
with potentially the Mandate Related Information (MRI) to the Debtor Agent immediately for information
purposes only.
In scope: The Debtor Agent sends a positive FIToFIPaymentStatusReport message to the Clearing and
Settlement
Agent. This positive status message may subsequently be forwarded to the Creditor Agent.
6.6 Payment Return with Direct Debit BusinessTransaction

A PaymentReturn message is initiated by the Debtor Agent and sent to the previous party in the payment
chain when a debit cannot be executed due to an administrative reason (such as non-existing/closed
account) or due to a banking reason (such as insufficient funds). The PaymentReturn message is also
the message to be used by the Debtor Agent following the receipt of a refund request by the Debtor as it
is assumed that the refund request will be done through a non-automated tool (such as phone/fax) and is
not part of the scope. In this case, the PaymentReturn message will contain a code to indicate that it is
triggered by a request for refund by the Debtor.
Scenario A:
PaymentReturn message initiated by the Debtor Agent
Page 30
Payments Initiation
Edition 31 May 2013
sending a positive
CustomerPaymentStatusReport to the Creditor.
applicable.
instruction by sending a positive FIToFIPaymentStatusReport message to the Creditor Agent.
potentially the
The Debtor Agent sends a positive FIToFIPaymentStatusReport message to the Clearing and Settlement
Agent.
If the Debtor Agent is unable to make the collection from the Debtor Account for one or several reasons
(insufficient funds, customer deceased...), he will initiate a PaymentReturn message, and route it through
the Clearing and Settlement Agent to the Creditor Agent, giving the reason for the Return.
The Clearing and Settlement Agent optionally confirms the receipt of the PaymentReturn message by
sending a positive FIToFIPaymentStatusReport message to the Debtor Agent.
The Clearing and Settlement Agent forwards the PaymentReturn message to the Creditor Agent.
Page 31
Payments Initiation
Edition 31 May 2013
In case the Clearing and Settlement Agent are two parties the Clearing Agent prepares the (returned)
payment information for the Settlement Agent (the net position to be debited, the party to be debited, the
net position to be credited, the party to be credited and the value date) in accordance with the agreed
and published settlement cycle. The Settlement Agent performs the transfer of cash from the credit party
to the debit party (in accordance with the agreed published settlement cycle). (Out of scope and not
illustrated).
The Creditor Agent will optionally confirm receipt of the PaymentReturn message to the Clearing and
Settlement Agent. Depending on agreements between the Creditor and the Creditor Agent, the Creditor
may be informed either through a negative CustomerPaymentStatusReport message, or through a
CustomerToBankDebitCreditNotification message ('notification') or through a
BankToCustomerAccountReport and/or BankToCustomerStatement message ('statement') about the
funds return and thus the debit on his account.
Scenario B:
Refund by the Debtor (Not illustrated in the Sequence Diagram)
This scenario is similar to the previous scenario, except that the PaymentReturn message by the Debtor
Agent to the Clearing and Settlement Agent is triggered by a Refund Request by the Debtor to his agent,
the Debtor Agent (in a non-automated manner). In this case, the PaymentReturn message will contain a
code indicating that it was triggered by a request for refund by the Debtor.
6.7 Customer Payment Reversal with Direct Debit BusinessTransaction

The Creditor will initiate a CustomerPaymentReversal message, after Settlement, when a paid Direct
Debit should not have been processed.
The Creditor Agent will in his turn initiate an FIToFIPaymentReversal message for the next agent in the
payment chain. Consequently, the Debtor will be credited back.
Note: The Creditor Agent may be the originator of a payment reversal - he will in this case initiate an
FIToFIPaymentReversal message.
Page 32
Payments Initiation
Edition 31 May 2013
The Creditor sends a CustomerDirectDebitInitiation message to its agent (the Creditor Agent).
sending a positive
applicable.
instruction by sending a positive FIToFIPaymentStatusReport message to the Creditor Agent.
potentially the
The Debtor Agent sends a positive FIToFIPaymentStatusReport message to the Clearing and Settlement
Agent. The Creditor realises this was a duplicated CustomerDirectDebitInitiation instruction. He now
wants to send a CustomerPaymentReversal message. He identifies the original
CustomerDirectDebitInitiation message (or a file of direct debit instructions) and generates an offsetting
transaction in favour of the Debtor, under the quotation of the reversal reasons. The Creditor Agent may
confirm the receipt of the CustomerPaymentReversal message by sending a positive
Page 33
Payments Initiation
Edition 31 May 2013
An FIToFIPaymentReversal message is submitted by the Creditor Agent to the Clearing and Settlement
Agent for settlement, under quotation of the original direct debit reference and the reason for the
reversal.
The Clearing Agent confirms the processability of the reversal by sending a positive
FIToFIPaymentStatusReport message to the Creditor Agent.
The Clearing and Settlement Agent forwards the FIToFIPaymentReversal message to the Debtor Agent
immediately for information purposes only.
In case the Clearing and Settlement Agent are two parties the Clearing Agent prepares the payment
information for the Settlement Agent (in accordance with the agreed and published settlement cycle).
That process includes the calculation of the settlement positions.
The information provided to the Settlement Agent is the net position to be debited, the party to be
debited, the net position to the credited, the party to be credited and the value date (Out of Scope).
The Settlement Agent performs the transfer of funds from the Credit Party to the Debit Party (in
accordance with the agreed and published settlement cycle) (Out of Scope).
A positive FIToFIPaymentStatusReport message can optionally be initiated by the Debtor Agent and sent
to the
Clearing and Settlement Agent to confirm the processability of the reversal message.
Note: it may exceptionally occur that a PaymentReturn message and a CustomerPaymentReversal
message would cross each other, this could only be avoided through value-added monitoring services
that could be offered by the scheme manager and/or this might provoke exceptions/investigation
handling.
Page 34
Payments Initiation
Edition 31 May 2013
7. Business examples
7.1 CustomerCreditTransferInitiation - Business Example 1
Narrative
ABC Corporation, New York has received three invoices:
1. An invoice with number 4562, dated 08 September 2012 from DEF Electronics, London: 10 million
JPY needs to be paid to DEF Electronics account 23683707994215 with AAAA Bank, London
(AAAAGB2L). ABC Corporation assigns reference ABC/4562/2012-09-08 to the payment. Payment
transaction charges are shared between ABC Corporation and DEF Electronics.
2. An invoice with number ABC-13679, dated 15 September 2012 from GHI Semiconductors, Brussels:
500,000 EUR needs to be paid to GHI Semiconductors account BE30001216371411 with DDDD Bank,
Belgium (DDDDBEBB). ABC Corporation assigns reference ABC/ABC-13679/2012-09-15 to the
payment. The accounts receivable department of GHI Semiconductors needs to be advised when the
funds have been credited on the account on telephone number
+32/2/2222222. GHI Semiconductors will bear all payment transaction charges.
3. An invoice with number 987-AC, dated 27 September 2012, from their branch ABC Corporation,
California: 1 million USD needs to be paid to the branch account 4895623 with BBBB Bank, San
Francisco (BBBBUS66). ABC assigns a reference ABC/987-AC/2012-09-27 to the payment. Payment
transaction charges are shared.
ABC Corporation holds an account 00125574999 with BBBB Bank, New York (BBBBUS33) and instructs
its bank to execute payment of the invoices with a CustomerCreditTransferInitiation message.
Business Description
CustomerCreditTransferInitiation from ABC Corporation, New York to BBBB Bank, New York:
Element
<XMLTag>
Content
Group Header
<GrpHdr>
MessageIdentification
<MsgId>
ABC/120928/CCT001
CreationDateTime
<CreDtTm>
2012-09-28T14:07:00
NumberOfTransactions
<NbOfTxs>
Controlsum
<CtrlSum>
11500000
InitiatingParty
<InitgPty>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Times Square
BuildingNumber
<BldgNb>
PostCode
<PstCd>
NY 10036
TownName
<TwnNm>
New York
Country
<Ctry>
US
PaymentInformation
<PmtInf>
PaymentInformationIdentification
<PmtInfId>
ABC/086
PaymentMethod
<PmtMtd>
TRF
BatchBooking
<BtchBookg>
FALSE
RequestedExecutionDate
<ReqdExctnDt>
2012-09-29
Debtor
<Dbtr>
Name
<Nm>
ABC Corporation
ABC Corporation
Page 35
Payments Initiation
Edition 31 May 2013
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Times Square
BuildingNumber
<BldgNb>
PostCode
<PstCd>
NY 10036
TownName
<TwnNm>
New York
Country
<Ctry>
US
DebtorAccount
<DbtrAcct>
Identification
<Id>
Other
<Othr>
Identification
<Id>
DebtorAgent
<DbtrAgt>
FinancialInstitutionIdentification
<FinInstnId>
BICFI
<BICFI>
00125574999
BBBBUS33
CreditTransferTransactionInformation <CdtTrfTxInf>
PaymentIdentification
<PmtId>
InstructionIdentification
<InstrId>
ABC/120928/CCT001/1
EndToEndIdentification
<EndToEndId>
ABC/4562/2012-09-08
Amount
<Amt>
InstructedAmount
<InstAmt>
JPY 10000000
ChargeBearer
<ChrgBr>
SHAR
CreditorAgent
<CdtrAgt>
<FinInstnId>
BICFI
<BICFI>
Creditor
<Cdtr>
Name
<Nm>
PostalAddress
<PstlAdr>
AddressLine
<AdrLine>
Corn Exchange 5th Floor
AddressLine
<AdrLine>
Mark Lane 55
AddressLine
<AdrLine>
EC3R7NE London
AddressLine
<AdrLine>
GB
CreditorAccount
<CdtrAcct>
Identification
<Id>
Other
<Othr>
Identification
<Id>
Purpose
<Purp>
Code
<Cd>
RemittanceInformation
<RmtInf>
Structured
<Strd>
ReferredDocumentInformation
<RfrdDocInf>
Type
<Type>
CodeOrProprietary
<CdOrPrtry>
AAAAGB2L
DEF Electronics
23683707994215
GDDS
Page 36
Payments Initiation
Edition 31 May 2013
Code
<Cd>
CINV
Number
<Nb>
4562
RelatedDate
<Dt>
2012-09-08
CreditTransferTransactionInformation <CdtTrfTxInf>
<PmtId>
<InstrId>
ABC/120928/CCT001/2
<EndToEndId>
Amount
<Amt>
ABC/ABC-13679/2012-0915
InstructedAmount
<InstdAmt>
EUR 500000
ChargeBearer
<ChrgBr>
CRED
CreditorAgent
<CdtrAgt>
<FinInstnId>
BICFI
<BICFI>
Creditor
<Cdtr>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Avenue Brugmann
BuildingNumber
<BldgNb>
415
PostCode
<PstCd>
1180
TownName
<TwnNm>
Brussels
Country
<Ctry>
BE
CreditorAccount
<CdtrAcct>
Identification
<Id>
IBAN
<IBAN>
InstructionForCreditorAgent
<InstrForCdtrAgt>
Code
<Cd>
PHOB
InstructionInformation
<InstrInf>
+32/2/2222222
Purpose
<Purp>
Code
<Cd>
<RmtInf>
Structured
<Strd>
<RfrdDocInf>
Type
<RfrdDocType>
CodeOrProprietary
<CdOrPrtry>
Code
<Cd>
CINV
Number
<Nb>
ABC-13679
RelatedDate
<RltdDt>
2012-09-15
CreditTransferTransactionInformation
<CdtTrfTxInf>
<PmtId>
<InstrId>
ABC/120928/CCT001/3
<EndToEndId>
ABC/987-AC/2012-09-27
DDDDBEBB
GHI Semiconductors
BE30001216371411
GDDS
Page 37
Payments Initiation
Edition 31 May 2013
Amount
<Amt>
InstructedAmount
<InstdAmt>
USD 1.000.000
ChargeBearer
<ChrgBr>
SHAR
CreditorAgent
<CdtrAgt>
<FinInstnId>
BICFI
<BICFI>
Creditor
<Cdtr>
Name
<Nm>
PostalAddress
<PstlAdr>
Department
<Dept>
Treasury department
StreetName
<StrtNm>
Bush Street
BuildingNumber
<BldgNb>
13
PostCode
<PstCd>
CA 94108
TownName
<TwnNm>
San Francisco
Country
<Ctry>
US
CreditorAccount
<CdtrAcct>
Identification
<Id>
Other
<Othr>
Identification
<Id>
Purpose
<Purp>
Code
<Cd>
<RmtInf>
Structured
<Strd>
<RfrdDocInf>
Type
<Type>
CodeOrProprietary
<CdOrPrtry>
Code
<Cd>
CINV
Number
<Nb>
987-AC
RelatedDate
<RltdDt>
2012-09-27
BBBBUS66
ABC Corporation
4895623
INTC
Message Instance
<CstmrCdtTrfInitn>
<GrpHdr>
<MsgId>ABC/120928/CCT001</MsgId>
<CreDtTm>2012-09-28T14:07:00</CreDtTm>
<NbOfTxs>3</NbOfTxs>
<CtrlSum>11500000</CtrlSum>
<InitgPty>
<Nm>ABC Corporation</Nm>
<PstlAdr>
<StrtNm>Times Square</StrtNm>
<BldgNb>7</BldgNb>
<PstCd>NY 10036</PstCd>
<TwnNm>New York</TwnNm>
<Ctry>US</Ctry>
</PstlAdr>
</InitgPty>
</GrpHdr>
<PmtInf>
<PmtInfId>ABC/086</PmtInfId>
Page 38
Payments Initiation
Edition 31 May 2013
<PmtMtd>TRF</PmtMtd>
<BtchBookg>false</BtchBookg>
<ReqdExctnDt>2012-09-29</ReqdExctnDt>
<Dbtr>
<PstlAdr>
<BldgNb>7</BldgNb>
<Ctry>US</Ctry>
</PstlAdr>
</Dbtr>
<DbtrAcct>
<Id>
<Othr>
<Id>00125574999</Id>
</Othr>
</Id>
</DbtrAcct>
<DbtrAgt>
<FinInstnId>
<BICFI>BBBBUS33</BICFI>
</FinInstnId>
</DbtrAgt>
<CdtTrfTxInf>
<PmtId>
<InstrId>ABC/120928/CCT001/01</InstrId>
<EndToEndId>ABC/4562/2012-09-08</EndToEndId>
</PmtId>
<Amt>
<InstdAmt Ccy="JPY">10000000</InstdAmt>
</Amt>
<ChrgBr>SHAR</ChrgBr>
<CdtrAgt>
<FinInstnId>
<BICFI>AAAAGB2L</BICFI>
</FinInstnId>
</CdtrAgt>
<Cdtr>
<Nm>DEF Electronics</Nm>
<PstlAdr>
<AdrLine>Corn Exchange 5th Floor</AdrLine>
<AdrLine>Mark Lane 55</AdrLine>
<AdrLine>EC3R7NE London</AdrLine>
<AdrLine>GB</AdrLine>
</PstlAdr>
</Cdtr>
<CdtrAcct>
<Id>
<Othr>
<Id>23683707994125</Id>
</Othr>
</Id>
</CdtrAcct>
<Purp>
<Cd>GDDS</Cd>
</Purp>
<RmtInf>
<Strd>
<RfrdDocInf>
<Tp>
<CdOrPrtry>
<Cd>CINV</Cd>
</CdOrPrtry>
</Tp>
<Nb>4562</Nb>
Page 39
Payments Initiation
Edition 31 May 2013
<RltdDt>2012-09-08</RltdDt>
</RfrdDocInf>
</Strd>
</RmtInf>
</CdtTrfTxInf>
<CdtTrfTxInf>
<PmtId>
<EndToEndId>ABC/ABC-13679/2012-09-15</EndToEndId>
</PmtId>
<Amt>
<InstdAmt Ccy="EUR">500000</InstdAmt>
</Amt>
<ChrgBr>CRED</ChrgBr>
<CdtrAgt>
<FinInstnId>
<BICFI>DDDDBEBB</BICFI>
</FinInstnId>
</CdtrAgt>
<Cdtr>
<Nm>GHI Semiconductors</Nm>
<PstlAdr>
<StrtNm>Avenue Brugmann</StrtNm>
<BldgNb>415</BldgNb>
<PstCd>1180</PstCd>
<TwnNm>Brussels</TwnNm>
<Ctry>BE</Ctry>
</PstlAdr>
</Cdtr>
<CdtrAcct>
<Id>
<IBAN>BE30001216371411</IBAN>
</Id>
</CdtrAcct>
<InstrForCdtrAgt>
<Cd>PHOB</Cd>
<InstrInf>+32/2/2222222</InstrInf>
</InstrForCdtrAgt>
<Purp>
<Cd>GDDS</Cd>
</Purp>
<RmtInf>
<Strd>
<RfrdDocInf>
<Tp>
<CdOrPrtry>
<Cd>CINV</Cd>
</CdOrPrtry>
</Tp>
<Nb>ABC-13679</Nb>
</RfrdDocInf>
</Strd>
</RmtInf>
</CdtTrfTxInf>
<CdtTrfTxInf>
<PmtId>
<EndToEndId>ABC/987-AC/2012-09-27</EndToEndId>
</PmtId>
<Amt>
<InstdAmt Ccy="USD">1000000</InstdAmt>
</Amt>
<CdtrAgt>
<FinInstnId>
Page 40
Payments Initiation
Edition 31 May 2013
</FinInstnId>
</CdtrAgt>
<Cdtr>
<PstlAdr>
<Dept>Treasury department</Dept>
<StrtNm>Bush Street</StrtNm>
<BldgNb>13</BldgNb>
<PstCd>CA 94108</PstCd>
<TwnNm>San Francisco</TwnNm>
<Ctry>US</Ctry>
</PstlAdr>
</Cdtr>
<CdtrAcct>
<Id>
<Othr>
<Id>4895623</Id>
</Othr>
</Id>
</CdtrAcct>
<Purp>
<Cd>INTC</Cd>
</Purp>
<RmtInf>
<Strd>
<RfrdDocInf>
<Tp>
<CdOrPrtry>
<Cd>CINV</Cd>
</CdOrPrtry>
</Tp>
<Nb>987-AC</Nb>
</RfrdDocInf>
</Strd>
</RmtInf>
</CdtTrfTxInf>
</PmtInf>
</CstmrCdtTrfInitn>
7.2 CustomerPaymentStatusReport - Business Example 1

Narrative
As follow-up to the payment initiation by ABC Corporation, BBBBUS33 sends a
CustomerPaymentStatusReport to acknowledge that the message passed technical validation and was
accepted based on the customer profile.
CustomerPaymentStatusReport from BBBB Bank to ABC Corporation
Element
<XMLTag>
Content
Group Header
<GrpHdr>
<MsgId>
CreationDateTime
<CreDtTm>
InitiatingParty
<InitgPty>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Times Square
BuildingNumber
<BldgNb>
BBBB/120928PSR/001
2012-09-28T14:09:00
ABC Corporation
Page 41
Payments Initiation
Edition 31 May 2013
PostCode
<PstCd>
NY 10036
TownName
<TwnNm>
New York
Country
<Ctry>
US
DebtorAgent
<DbtrAgt>
<FinInstnId>
BICFI
<BICFI>
BBBBUS33
OriginalGroupInformationAndStatus <OrgnlGrpInfAndSts
>
OriginalMessageIdentification
<OrgnlMsgId>
ABC/120928/CCT001
OriginalMessageNameIdentification <OrgnlMsgNmId>
pain.001.001.05
OriginalCreationDateTime
<OrgnlCreDtTm>
2012-09-28T14:07:00
OriginalNumberOfTransactions
<OrgnlNbOfTxs>
OriginalControlSum
<OrgnlCtrlSm>
1.1500.000
GroupStatus
<GrpsSts>
ACCP
Message Instance
<CstmrPmtStsRpt>
<GrpHdr>
<MsgId>BBBB/120928-PSR/001</MsgId>
<InitgPty>
<PstlAdr>
<BldgNb>7</BldgNb>
<Ctry>US</Ctry>
</PstlAdr>
</InitgPty>
<DbtrAgt>
<FinInstnId>
</FinInstnId>
</DbtrAgt>
</GrpHdr>
<OrgnlGrpInfAndSts>
<OrgnlMsgId>ABC/120928/CCT001</OrgnlMsgId>
<OrgnlMsgNmId>pain.001.001.05</OrgnlMsgNmId>
<OrgnlCreDtTm>2012-09-28T14:07:00</OrgnlCreDtTm>
<OrgnlNbOfTxs>3</OrgnlNbOfTxs>
<OrgnlCtrlSum>11500000</OrgnlCtrlSum>
<GrpSts>ACCP</GrpSts>
</OrgnlGrpInfAndSts>
</CstmrPmtStsRpt>
7.3 CustomerPaymentStatusReport - Business Example 2

Narrative
AAAAUS29 received an FIToFIPaymentStatusReport from its correspondent, ABABUS23, containing
reject information about a previously sent FIToFICustomerDirectDebit. As AAAAUS29 has not yet
credited the account of the original initiating party (Virgay) of the direct debit, AAAAUS29 in its turn
informs Virgay about the rejection of the CustomerDirectDebitInitiation sent on 28 June 2012.
CustomerPaymentStatusReport from AAAAUS29 to Virgay:
Element
<XMLTag>
Content
Page 42
Payments Initiation
Edition 31 May 2013
Group Header
<GrpHdr>
<MsgId>
AAAAUS29_5678c
CreationDateTime
<CreDtTm>
2012-06-29T15:49:00
InitiatingParty
<InitgPty>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Virginia Lane
BuildingNumber
<BldgNb>
36
PostCode
<PstCd>
NJ 07311
TownName
<TwnNm>
Jersey City
Country
<Ctry>
US
CreditorAgent
<CdtrAgt>
<FinInstnId>
BICFI
<BICFI>
OriginalGroupInformationAndStat
us
<OrgnGrpInfAndSts>
<OrgnlMsgId>
CAVAY1234
OriginalMessageName
Identification
OriginalCreationDateAndTime
<OrgnlMsgNmId>
pacs.003.001.04
<OrgnlCreDtTm>
2012-06-28T14:25:00
Virgay
AAAAUS29
OriginalPaymentInformationAndSt <OrgnlPmmtInfSts>
atus
OriginalPaymentInformationIdentific <OrgnlPmtInfId>
a tion
JKL_774
TransactionInformationAndStatus
<TxInfAndSts>
StatusID
<StsId>
RJT2012_657B
OriginalEndToEndIdentification
<OrgnlEndToEndId>
VA100327/0123
TransactionStatus
<TxSts>
RJCT
StatusReasonInformation
<StsRsnInf>
Originator
<Orgtr>
OrganisationIdentification
<OrgId>
AnyBIC
<AnyBIC>
Reason
<StsRsn>
Code
<Cd>
OriginalTransactionReference
<OrgnlTxRef>
Amount
<Amt>
InstructedAmount
<InstAmt>
USD 1025
RequestedCollectionDate
<ReqdColltnDt>
2012-07-02
MandateRelatedInformation
<MndtRltdInf>
MandateIdentification
<MndtId>
Debtor
<Dbtr>
Name
<Name>
PostalAddress
<PstlAdr>
ABABUS23
AM05
VIRGAY123
Jones
Page 43
Payments Initiation
Edition 31 May 2013
StreetName
<StrtNm>
Hudson Street
BuildingNumber
<BldgNb>
19
PostCode
<PstCd>
NJ 07302
TownName
<TwnNm>
Jersey City
Country
<Ctry>
US
Creditor
<Cdtr>
Name
<Name>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Virginia Lane
BuildingNumber
<BldgNb>
36
PostCode
<PstCd>
NJ 07311
TownName
<TwnNm>
Jersey City
Country
<Ctry>
US
Virgay
Message Instance
<CstmrPmtStsRpt>
<GrpHdr>
<MsgId>AAAAUS29_5678c</MsgId>
<InitgPty>
<Nm>Virgay</Nm>
<PstlAdr>
<StrtNm>Virginia Lane</StrtNm>
<BldgNb>36</BldgNb>
<PstCd>NJ 07311</PstCd>
<TwnNm>Jersey City</TwnNm>
<Ctry>US</Ctry>
</PstlAdr>
</InitgPty>
<CdtrAgt>
<FinInstnId>
<BICFI>AAAAUS29</BICFI>
</FinInstnId>
</CdtrAgt>
</GrpHdr>
<OrgnlGrpInfAndSts>
<OrgnlMsgId>CAVAY1234</OrgnlMsgId>
<OrgnlMsgNmId>pacs.003.001.04</OrgnlMsgNmId>
</OrgnlGrpInfAndSts>
<OrgnlPmtInfAndSts>
<OrgnlPmtInfId>JKL_774</OrgnlPmtInfId>
<TxInfAndSts>
<StsId>RIT2012 657B</StsId>
<OrgnlEndToEndId>VA100327/0123</OrgnlEndToEndId>
<TxSts>RJCT</TxSts>
<StsRsnInf>
<Orgtr>
<Id>
<OrgId>
<AnyBIC>ABABUS23</AnyBIC>
</OrgId>
</Id>
</Orgtr>
<Rsn>
<Cd>AM05</Cd>
</Rsn>
</StsRsnInf>
<OrgnlTxRef>
<Amt>
Page 44
Payments Initiation
Edition 31 May 2013
</Amt>
<ReqdColltnDt>2012-07-02</ReqdColltnDt>
<MndtRltdInf>
<MndtId>VIRGAY123</MndtId>
</MndtRltdInf>
<Dbtr>
<Nm>Jones</Nm>
<PstlAdr>
<StrtNm>Hudson Street</StrtNm>
<BldgNb>19</BldgNb>
<Ctry>US</Ctry>
</PstlAdr>
</Dbtr>
<Cdtr>
<Nm>Virgay</Nm>
<PstlAdr>
<BldgNb>36</BldgNb>
<Ctry>US</Ctry>
</PstlAdr>
</Cdtr>
</OrgnlTxRef>
</TxInfAndSts>
</OrgnlPmtInfAndSts>
</CstmrPmtStsRpt>
7.4 CustomerPaymentReversal - Business Example 1

Narrative
On 17 June 2012, date of the collection from debtor Schneider, Ritcom electricity company realizes that
the direct debit instruction sent on 9 June 2012 was a duplicated instruction. As settlement of the direct
debit already took place,
Ritcom electricity company initiates a CustomerPaymentReversal message and sends it to its account
servicer AAAADEFF. Any potential charges relating to this reversal payment, paid by Schneider, will be
deducted from the next invoice.
CustomerPaymentReversal from Ritcom to AAAADEFF :
Element
<XMLTag>
Content
Group Header
<GrpHdr>
<MsgId>
RIT-REV-20120617-456f
CreationDateTime
<CreDtTm>
2012-06-17T15:38:00
<NbOfTxs>
InitiatingParty
<InitgPty>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Schueman Strasse
BuildingNumber
<BldgNb>
18
PostCode
<PstCd>
60017
TownName
<TwnNm>
Frankfurt am Main
Ritcom
Page 45
Payments Initiation
Edition 31 May 2013
Country
<Ctry>
DE
DebtorAgent
<DbtrAgt>
<FinInstnId>
BICFI
<BICFI>
CreditorAgent
<CdtrAgt>
<FinInstnId>
BICFI
<BICFI>
OriginalGroupInformation
<OrgnlGrpInf>
<OrgnlMsgId>
RITCOM1234
OriginalMessageName
Identification
OriginalCreationDateAndTime
<OrgnlMsgNmId>
pain.008.001.04
<OrgnlCreDtTm>
2012-06-09T09:18:00
OriginalPaymentInformationAndR
eversal
<OrgnlPmtInfAndRvsl>
BBBBDE33
AAAADEFF
OriginalPaymentInformationIdentific <OrgnlPmtInfId>
a tion
TransactionInformation
<TxInf>
RIT/0053
ReversalIdentification
<RvslId>
RIT5467
OriginalEndToEndIdentification
<OrgnlEndToEnd>
RIT/012010-2562C26
OriginalInstructedAmount
<OrgnlInstdAmt>
EUR 286
ReversedInstructedAmount
<RvsdInstdAmt>
EUR 286
ReversalReasonInformation
<RvslRsnInf>
Originator
<Orgtr>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Schueman Strasse
BuildingNumber
<BldgNb>
18
PostCode
<PstCd>
60017
TownName
<TwnNm>
Frankfurt am Main
Country
<Ctry>
DE
Reason
<Rsn>
Code
<Cd>
OriginalTransactionReference
<OrgnlTxRef>
<ReqdColltnDt>
<MndtRltdInf>
<MndtId>
Debtor
<Dbtr>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Kuertman Strasse
BuildingNumber
<BldgNb>
45
PostCode
<PstCd>
50475
TownName
<TwnNm>
Koln
Ritcom
AM05
2012-06-16
RIT04/av002
Schneider
Page 46
Payments Initiation
Edition 31 May 2013
Country
<Ctry>
DE
DebtorAccount
<DbtrAcct>
Identification
<Id>
IBAN
<IBAN>
Creditor
<Cdtr>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Schueman Strasse
BuildingNumber
<BldgNb>
18
PostCode
<PstCd>
60017
TownName
<TwnNm>
Frankfurt am Main
Country
<Ctry>
DE
DE89370400440332013000
Ritcom
Message Instance
<CstmrPmtRvsl>
<GrpHdr>
<MsgId>RIT-REV-20120617-456f</MsgId>
<InitgPty>
<Nm>Ritcom</Nm>
<PstlAdr>
<StrtNm>Schueman Strasse</StrtNm>
<BldgNb>18</BldgNb>
<PstCd>60017</PstCd>
<TwnNm>Frankfurt am Main</TwnNm>
<Ctry>DE</Ctry>
</PstlAdr>
</InitgPty>
<DbtrAgt>
<FinInstnId>
<BICFI>BBBBDE33</BICFI>
</FinInstnId>
</DbtrAgt>
<CdtrAgt>
<FinInstnId>
<BICFI>AAAADEFF</BICFI>
</FinInstnId>
</CdtrAgt>
</GrpHdr>
<OrgnlGrpInf>
<OrgnlMsgId>RITCOM1234</OrgnlMsgId>
<OrgnlMsgNmId>pain.008.001.04</OrgnlMsgNmId>
</OrgnlGrpInf>
<OrgnlPmtInfAndRvsl>
<OrgnlPmtInfId>RIT/0053</OrgnlPmtInfId>
<TxInf>
<RvslId>RIT5467</RvslId>
<OrgnlEndToEndId>RIT/012010-2562C26</OrgnlEndToEndId>
<OrgnlInstdAmt Ccy="EUR">286</OrgnlInstdAmt>
<RvsdInstdAmt Ccy="EUR">286</RvsdInstdAmt>
<RvslRsnInf>
<Orgtr>
<Nm>Ritcom</Nm>
<PstlAdr>
<BldgNb>18</BldgNb>
Page 47
Payments Initiation
Edition 31 May 2013
<Ctry>DE</Ctry>
</PstlAdr>
</Orgtr>
<Rsn>
<Cd>AM05</Cd>
</Rsn>
</RvslRsnInf>
<OrgnlTxRef>
<MndtRltdInf>
<MndtId>RIT04/av002</MndtId>
</MndtRltdInf>
<Dbtr>
<Nm>Schneider</Nm>
<PstlAdr>
<StrtNm>Kuertman Strasse</StrtNm>
<BldgNb>45</BldgNb>
<TwnNm>Koln</TwnNm>
<Ctry>DE</Ctry>
</PstlAdr>
</Dbtr>
<DbtrAcct>
<Id>
<IBAN>DE89370400440332013000</IBAN>
</Id>
</DbtrAcct>
<Cdtr>
<Nm>Ritcom</Nm>
<PstlAdr>
<BldgNb>18</BldgNb>
<Ctry>DE</Ctry>
</PstlAdr>
</Cdtr>
</OrgnlTxRef>
</TxInf>
</OrgnlPmtInfAndRvsl>
</CstmrPmtRvsl>
7.5 CustomerDirectDebitInitiation - Business Example 1

Narrative
On 2 June 2012, Virgay insurance company sends a CustomerDirectDebitInitiation message to its
account servicer, AAAAUS29. AAAAUS29 offers a special service to Virgay, under agreement VERPA-1.
The direct debit initiation message contains two collection instructions from two different debtors.
The first direct debit instruction is for 1025 USD to be collected from account 123456, owned by debtor
Jones and serviced by agent BBBBUS39. The mandate reference is VIRGAY123 and was signed by
Jones on 13 July 2008. The last collection is due to take place on 13 July 2015. The payment is for a
yearly life insurance fee.
The second direct debit instruction is for 985 USD to be collected from account 789101, owned by debtor
Lee and serviced by agent CCCCUS27. This is a one-off direct debit which has been notified to Lee on 8
June 2012, with reference VIRGAY2435/2012. The payment is for a car insurance premium.
The requested collection date for both collections is 13 July 2012 and charges related to the handling of
the instruction will be shared between Virgay insurance company and the debtors.
CustomerDirectDebitInitiation from Virgay to AAAAUS29:
Page 48
Payments Initiation
Edition 31 May 2013
Element
<XMLTag>
Content
Group Header
<GrpHdr>
<MsgId>
CAVAY1234
CreationDateTime
<CreDtTm>
2012-06-02T14:25:00
<NbOfTxs>
ControlSum
<CtrlSum>
2010
InitiatingParty
<InitgPty>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Virginia Lane
BuildingNumber
<BldgNb>
36
PostCode
<PstCd>
NJ 07311
TownName
<TwnNm>
Jersey City
Country
<Ctry>
US
Contactdetails
<CtctDtls>
Name
<Nm>
J. Thompson
EmailAddress
<EmailAdr>
[email protected]
PaymentInformation
<PmtInf>
PaymentInformationIdentification
<PmtInfId>
CAVAY/88683
PaymentMethod
<PmtMtd>
DD
BatchBooking
<BtchBookg>
FALSE
<ReqColltnDt>
2012-07-13
Creditor
<Cdtr>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Virginia Lane
BuildingNumber
<BldgNb>
36
PostCode
<PstCd>
NJ 07311
TownName
<TwnNm>
Jersey City
Country
<Ctry>
US
CreditorAccount
<CdtrAcct>
Identification
<Id>
Other
<Othr>
Identification
<Id>
CreditorAgent
<CdtrAgt>
<FinInstnId>
BICFI
<BICFI>
Virgay
Virgay
789123
AAAAUS29
DirectDebitTransactionInformation <DrctDbtTxInf>
<PmtId>
<EndToEndId>
PaymentTypeInformation
<PmtTpInf>
VA060327/0123
Page 49
Payments Initiation
Edition 31 May 2013
InstructionPriority
<InstrPrty>
NORM
ServiceLevel
<SvcLvl>
Proprietary
<Prtry>
VERPA-1
SequenceType
<SeqTp>
RCUR
InstructedAmount
<InstdAmt>
USD 1025
ChargeBearer
<ChrBr>
SHAR
DirectDebitTransaction
<DrctDbtTx>
<MndtRltInf>
<MndtId>
VIRGAY123
DateOfSignature
<DtOfSgntr>
2008-07-13
FinalCollectionDate
<FnlColltnDt>
2015-07-13
Frequency
<Frqcy>
YEAR
DebtorAgent
<DbtrAgt>
<FinInstnId>
BICFI
<BICFI>
Debtor
<Dbtr>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Hudson Street
BuildingNumber
<BldgNb>
19
PostCode
<PstCd>
NJ 07302
TownName
<TwnNm>
Jersey City
Country
<Ctry>
US
DebtorAccount
<DbtrAcct>
Identification
<Id>
Other
<Othr>
Identification
<Id>
Purpose
<Purp>
Code
<Cd>
<RmtInf>
Unstructured
<Ustrd>
BBBBUS39
Jones
123456
LIFI
LIFE INSURANCE PAYMENT/
JULY 2012
DirectDebitTransactionInformation
<DrctDbtTxInf>
<PmtId>
<EndToEndId>
PaymentTypeInformation
<PmtTpInf>
InstructionPriority
<InstrPrty>
ServiceLevel
<SvcLvl>
Proprietary
<Prtry>
VERPA-1
SequenceType
<SeqTp>
OOFF
InstructedAmount
<InstdAmt>
USD 985
ChargeBearer
<ChrBr>
SHAR
AY090327/456
NORM
Page 50
Payments Initiation
Edition 31 May 2013
DirectDebitTransaction
<DrctDbtTx>
PreNotificationIdentification
<PreNtfctnId>
VIRGAY2435/2012
PreNotificationDate
<PreNtfctnDt>
2012-06-08
DebtorAgent
<DbtrAgt>
<FinInstnId>
BICFI
<BICFI>
Debtor
<Dbtr>
Name
<Nm>
PostalAddress
<PstlAdr>
StreetName
<StrtNm>
Cross Road
BuildingNumber
<BldgNb>
45
PostCode
<PstCd>
NJ 07399
TownName
<TwnNm>
Jersey City
Country
<Ctry>
US
DebtorAccount
<DbtrAcct>
Identification
<Id>
Other
<Othr
Identification
<Id>
<RmtInf>
Unstructured
<Ustrd>
CCCCUS27
Lee
789101
CAR INSURANCE PREMIUM
Message Instance
<CstmrDrctDbtInitn>
<GrpHdr>
<MsgId>CAVAY1234</MsgId>
<CtrlSum>2010</CtrlSum>
<InitgPty>
<Nm>Virgay</Nm>
<PstlAdr>
<BldgNb>36</BldgNb>
<Ctry>US</Ctry>
</PstlAdr>
<CtctDtls>
<Nm>J. Thompson</Nm>
<EmailAdr>[email protected]</EmailAdr>
</CtctDtls>
</InitgPty>
</GrpHdr>
<PmtInf>
<PmtInfId>CAVAY/88683</PmtInfId>
<PmtMtd>DD</PmtMtd>
<BtchBookg>false</BtchBookg>
<Cdtr>
<Nm>Virgay</Nm>
<PstlAdr>
<BldgNb>36</BldgNb>
Page 51
Payments Initiation
Edition 31 May 2013
<Ctry>US</Ctry>
</PstlAdr>
</Cdtr>
<CdtrAcct>
<Id>
<Othr>
<Id>789123</Id>
</Othr>
</Id>
</CdtrAcct>
<CdtrAgt>
<FinInstnId>
<BICFI>AAAAUS29</BICFI>
</FinInstnId>
</CdtrAgt>
<DrctDbtTxInf>
<PmtId>
<EndToEndId>VA060327/0123</EndToEndId>
</PmtId>
<PmtTpInf>
<InstrPrty>NORM</InstrPrty>
<SvcLvl>
<Prtry>VERPA-1</Prtry>
</SvcLvl>
<SeqTp>RCUR</SeqTp>
</PmtTpInf>
<DrctDbtTx>
<MndtRltdInf>
<MndtId>VIRGAY123</MndtId>
<DtOfSgntr>2008-07-13</DtOfSgntr>
<FnlColltnDt>2015-07-13</FnlColltnDt>
<Frqcy>YEAR</Frqcy>
</MndtRltdInf>
</DrctDbtTx>
<DbtrAgt>
<FinInstnId>
</FinInstnId>
</DbtrAgt>
<Dbtr>
<Nm>Jones</Nm>
<PstlAdr>
<StrtNm>Hudson Street</StrtNm>
<BldgNb>19</BldgNb>
<Ctry>US</Ctry>
</PstlAdr>
</Dbtr>
<DbtrAcct>
<Id>
<Othr>
<Id>123456</Id>
</Othr>
</Id>
</DbtrAcct>
<Purp>
<Cd>LIFI</Cd>
</Purp>
<RmtInf>
<Ustrd>LIFE INSURANCE PAYMENT/ JULY 2012</Ustrd>
</RmtInf>
</DrctDbtTxInf>
<DrctDbtTxInf>
<PmtId>
Page 52
Payments Initiation
Edition 31 May 2013
<EndToEndId>AY090327/456</EndToEndId>
</PmtId>
<PmtTpInf>
<InstrPrty>NORM</InstrPrty>
<SvcLvl>
<Prtry>VERPA-1</Prtry>
</SvcLvl>
<SeqTp>OOFF</SeqTp>
</PmtTpInf>
<DrctDbtTx>
<PreNtfctnId>VIRGAY2435/2012</PreNtfctnId>
<PreNtfctnDt>2012-06-08</PreNtfctnDt>
</DrctDbtTx>
<DbtrAgt>
<FinInstnId>
<BICFI>CCCCUS27</BICFI>
</FinInstnId>
</DbtrAgt>
<Dbtr>
<Nm>Lee</Nm>
<PstlAdr>
<StrtNm>Cross Road</StrtNm>
<BldgNb>45</BldgNb>
<PstCd>NJ07399</PstCd>
<Ctry>US</Ctry>
</PstlAdr>
</Dbtr>
<DbtrAcct>
<Id>
<Othr>
<Id>789101</Id>
</Othr>
</Id>
</DbtrAcct>
<RmtInf>
<Ustrd>CAR INSURANCE PREMIUM</Ustrd>
</RmtInf>
</DrctDbtTxInf>
</PmtInf>
</CstmrDrctDbtInitn>
Page 53
Payments Initiation
Edition 31 May 2013
8. Revision Record
Revision
Date
Author
Description
Sections affected
1.0
25/02/2013
ISO 20022 RA
First version in line

with ISO20022
Edition 2013
All
2.0
01/03/2013
ISO 20022 RA
Feedback from
development team
All
Disclaimer:
Although the Registration Authority has used all reasonable efforts to ensure accuracy of the contents of the
iso20022.org website and the information published thereon, the Registration Authority assumes no liability
whatsoever for any inadvertent errors or omissions that may appear thereon. Moreover, the information is provided
on an "as is" basis. The Registration Authority disclaims all warranties and conditions, either express or implied,
including but not limited to implied warranties of merchantability, title, non-infringement and fitness for a particular
purpose.
The Registration Authority shall not be liable for any direct, indirect, special or consequential damages arising out of
the use of the information published on the iso20022.org website, even if the Registration Authority has been
advised of the possibility of such damages.
Intellectual Property Rights:
The ISO 20022 MessageDefinitions described in this document were contributed by SWIFT. The ISO 20022 IPR
policy is available at www.ISO20022.org > About ISO 20022 > Intellectual Property Rights.
Page 54

ISO20022 PaymentsInitiation MDR1 PDF

Uploaded by

Copyright:

Available Formats

ISO20022 PaymentsInitiation MDR1 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ISO20022 PaymentsInitiation MDR1 PDF

Uploaded by

Copyright:

Available Formats

What is the scope and functionality of the document?

What is the scope and functionality of the document?

What business roles and participants are described?

What business roles and participants are described?

ISO 20022

Payments Initiation May 2013

Message Definition Report - Part 1

Edition 31 May 2013

Edition 31 May 2013

Scope and Functionality ............................................................................................6

BusinessRoles and Participants................................................................................7

Description of BusinessActivities ........................................................................... 13

Business examples ..................................................................................................35

Revision Record .......................................................................................................54

Message Definition Report Part 1

Edition 31 May 2013

functional role played by a business actor in a particular BusinessProcess or

involvement of a BusinessRole in a BusinessTransaction

unrealized definition of the business activities undertaken by BusinessRoles

formal description of the structure of a message instance

International Standards Team Harmonisation

Corporate Straight Trough Processing Bank Group

Corporate Advisory Group

International Securities Association for Institutional Trade Communication

Interactive Financial eXchange Forum

Transaction Workflow Innovation Standards Team

Corporate Banking Interbancario

Open Application Group

Message Definition Report

Message change request

Standards Evaluation Group

eXtensible Mark-up Language

International Bank Account Number

Business Identifier Code

Automated Clearing House

Mandate Related Information

Message Definition Report Part 1

Edition 31 May 2013

For example (exempli gratia)

That is (id est)

1.3 Document Scope and Objectives

The BusinessProcess scope (business processes addressed or impacted by the project)

The BusinessRoles involved in these BusinessProcesses

The main objectives of this document are:

To explain what BusinessProcesses and BusinessActivities these MessageDefinitions have

To give a high level description of BusinessProcesses and the associated BusinessRoles

To document the BusinessTransactions and their Participants (sequence diagrams)

To list the MessageDefinitions

To list the Business samples

ISO 20022 Business Justification Customer to Bank

ISO 20022 Message Definition Report (MDR)

ISO 20022 Message Definition Report (MDR)

ISO 20022 Message Usage Guide (MUG)

Message Definition Report Part 1

CSTP and the

Edition 31 May 2013

ISO 20022 Maintenance Change Request (MCR)

ISO 20022 Message Definition Report (MDR)

ISO 20022 Maintenance Change Request (MCR)