Real-Time Payments: Actors and Message Flows Overview

 
What is covered in this document?
 
ISO 20022 RTPG Message Flows
 
Page 1
 
For more information on the ISO 20022 Real Time Payments Group
visit us at 
https://www.iso20022.org/payments_rtpg.page
 
Initiating
party
 
Debtor
 
Forwarding
 agent
 
Ultimate
   Debtor
 
Creditor
 
       Ultimate
       Creditor
 
Debtor
agent
 
Instructing
agent
 
Instructed
agent
 
Creditor
agent
 
Reimbursement agents
 
Intermediary agents
 
Previous
Instructing agent
 
Actors: Payments Message Flow
 
1
 
2
 
3
 
Instruct
ing
 
Instruct
ed
 
Third
 
The following message flows are intended to depict the exchange of payment items
between Financial Institutions in the clearing process using ISO 20022 messages.
 
Note: In a real-time scenario, it is only expected that the chain will extend to
Debtor/Creditor and one Intermediary Agent (as a maximum).
 
ISO 20022 RTPG Message Flows
 
Page 2
 
Real-Time Payments: Message Portfolio
 
ISO 20022 RTPG Message Flows
 
3
 
‘Core’ Payment
messages
 
‘Optional’ usage and driven by
system design and market usage
ORCHESTRATION MESSAGES*
SETTLEMENT MESSAGES
pacs.009
pacs.010
 
* The ISO 20022 catalogue offers a vast range of
orchestration messages
 
*Flow #1: BASIC CUSTOMER CREDIT TRANSFER FLOW
(The Happy flow)
 
ISO 20022 RTPG Message Flows
 
Page 4
 
1.
The Debtor initiates a credit transfer to the
Debtor Agent, using a pain.001 or similar
message.
2.
Based on the credit transfer initiation
message, the Debtor Agent sends a pacs.008
to the MI which sends
 
on the message to the
Creditor Agent.
3.
The Creditor Agent validates the pacs.008
and sends a positive pacs.002 back to the MI
to confirm that the message was valid.
4.
The MI then delivers a pacs.002 to the
Debtor Agent and to the Creditor Agent to
advise that the transaction has been
completed.
5.
Upon receipt of the pacs.002 from the
Central Switch, the Debtor Agent will notify
the Debtor  and the Creditor Agent will notify
the Creditor that the Transaction was
successfully completed.
 
[Note: this basic flow will repeat in most
process flows depicted within and as such shall
be identified as 
Flow #1]
 
Flow #2: 
Rejection By Creditor Bank (Account Closed)
(An Unhappy Flow)
 
ISO 20022 RTPG Message Flows
 
Page 5
 
Note: 
“Account Closed” is one of a number of reasons a transaction may be rejected.
 
Account
Closed
 
DEBTOR
MI
 
CREDITOR
1
2
3
 
DEBTOR AGENT
 
CREDITOR AGENT
2
PACS.008
PACS.008
3
PACS.002
4
PACS.002
5
 
x
 
1.
The Debtor initiates a credit transfer
initiation message, using a pain.001 or
similar message, to the Debtor Agent.
2.
Based on the credit transfer initiation
message, the Debtor Agent sends a
pacs.008 to the MI which then sends
the message to the Creditor Agent.
3.
The Creditor Agent conducts the
necessary checks and notices the
Creditor account is closed. The Agent
will reject the pacs.008 by sending a
negative
 pacs.002 with the appropriate
reason code for rejection to the MI.
4.
The MI will then deliver a pacs.002 to
the Debtor Agent to advise that the
transaction was not completed.
 
Flow #3: Pain.013 and pain.014 
(Optional Service)
 
ISO 20022 RTPG Message Flows
 
Page 6
 
ISO 20022 RTPG Message Flows
 
1.
The Creditor initiates the request for payment to the
Creditor Agent (using a pain.013 or similar message).
2.
The Creditor Agent will initiate a pain.013 message directly
or via the MI to the Debtor Agent.
3.
The Debtor Agent notifies the Debtor of the payment
request and responses 
in accordance with the scheme rules
.
4.
In the event of a negative response, a need to provide
information, or a change in the payment details
, the
Debtor may respond using  a pain.014
+
 (or similar message)
to the Debtor Agent with appropriate response included.
5.
The Debtor Agent delivers the response to the Creditor
Agent, directly or via the MI, using a pain.014.
6.
The Creditor Agent notifies the Creditor of the Debtor’s
response as appropriate using the pain.014 or similar
message.
7.
In the event of a positive response
, the Debtor may initiate
a payment instruction to the Debtor Agent* and a process
flow largely in the form of 
Flow #1
 shall take place.
+
 Pain.014 should be used to provide a negative response to a
pain.013 or an amendment to the pain.013.
* This step is dependant on the service offerings of the Debtor
Agent. Usually the Debtor Agent would create the pacs.008 as
a service to its client.
 
Flow #4: REMT.001 and REMT.002 
(Optional Service)
 
Page 7
 
ISO 20022 RTPG Message Flows
 
DEBTOR
MI
 
CREDITOR
 
DEBTOR AGENT
 
CREDITOR AGENT
REMT.001 or 002
REMT.001 or 002
 
* The remt.001 may or may not follow the same route/channel as 
Flow #1 
and will contain Identification and Location
information.  It can also be made available in a Remittance Database/Repository.
 
The corresponding Flow #1 may be initiated at
any time before, during or after this process.
 
1.
The Debtor may also deliver a Remittance
Advice or a Remittance Location Advice
message, using a remt.001/002 or similar
messages, to the Debtor Agent 
(or, to
another service provider or directly to the
Creditor)
 
2.
The Debtor Agent 
(or other service provider)
delivers the remt.001/002 message to
Creditor Agent 
(or the Creditor)
 
3.
The Creditor Agent also delivers the
Remittance Advice and Location Advice
messages 
(if applicable) 
to the Creditor
1
2
2
3
 
ISO 20022 RTPG Message Flows
 
Flow #6: 
Cancellation Request, Request for Return of
Funds and Resolution of Investigation 
(Optional Service)
 
DEBTOR
MI
 
CREDITOR
 
DEBTOR AGENT
 
CREDITOR AGENT
6
PACS.002
5
7
7
CAMT.056
CAMT.056
6
PACS.002
3
3
4
4
2
CAMT.029
CAMT.029
PACS.008/004
5
PACS.008/004
 
A cancellation request or a request for return of funds would
be initiated following 
Flow #1
.
3.
After a period of 
time
, upon instruction from the Debtor
or in accordance with agreements, the Debtor Agent
delivers a payment cancellation request using a camt.056
seeking to return (cancel) the initial pacs.008 payment.
The Creditor Agent upon receipt of the camt.056 will
await a response from the Creditor to return (cancel) the
payment.
4.
The Creditor Agent shall respond to the cancellation
request by delivering a Resolution of Investigation
message (camt.029) in the event of a negative or positive
response to the request for return (cancelation).
5.
Depending on the framework, in the event of a positive
response, 
the Creditor Agent may also issue a pacs.004
or 008 depending to return the payment, to the Central
Switch which sends
 
on the message to the Debtor Agent.
6.
The Central Switch will then deliver a pacs.002 to the
Debtor Agent and to the Creditor Agent to advise that
the transaction has been completed.
7.
Upon receipt of the pacs.002 (optional) from the Central
Switch, the Debtor Agent will notify the Debtor  and the
Creditor Agent will notify the Creditor that the
Transaction was successfully completed.
 
* In a real-time environment, the camt.056 is being used
more and more as a 
Request for Return 
of a payment that
has already been settled.
Settlement Models
 
1.
Deferred Net Settlement
2.
Real Time Settlement
3.
Hybrid Settlement
 
ISO 20022 RTPG Message Flows
 
9
 
ISO 20022 RTPG Message Flows
 
SETTLEMENT MODELS
 
ISO 20022 RTPG Message Flows
 
10
 
ISO 20022 RTPG Message Flows
 
SETTLEMENT MODELS Cont’d
 
ISO 20022 RTPG Message Flows
 
11
 
ISO 20022 RTPG Message Flows
 
SETTLEMENT MODELS Cont’d
 
ISO 20022 RTPG Message Flows
 
12
 
ISO 20022 RTPG Message Flows
Slide Note
Embed
Share

This document provides an overview of the actors involved in a payment flow and the message portfolio in Real-Time Payments (RTP). It includes details on various actors like Instructing agent, Forwarding agent, Ultimate Debtor, Reimbursement agents, and more. The provided message flows illustrate the exchange of payment items between Financial Institutions in the clearing process using ISO 20022 messages, with a focus on flows like basic customer credit transfer and rejection by the Creditor Bank.

  • Real-Time Payments
  • Payment Flows
  • ISO 20022
  • Actors
  • Message Portfolio

Uploaded on Jul 19, 2024 | 2 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. What is covered in this document? RTP: Actors in a Payment Flow RTP: Message Portfolio RTP: Portfolio Glossary of Message RTP: Portfolio Message Flows For more information on the ISO 20022 Real Time Payments Group visit us at https://www.iso20022.org/payments_rtpg.page Page 1 ISO 20022 RTPG Message Flows

  2. Actors: Payments Message Flow Previous Instructing agent Forwarding agent Ultimate Ultimate Debtor Reimbursement agents Intermediary agents Creditor 2 3 Instruct ing Third Instruct ed 1 Instructed agent Instructing agent Creditor Creditor agent Debtor agent Initiating party Debtor The following message flows are intended to depict the exchange of payment items between Financial Institutions in the clearing process using ISO 20022 messages. Note: In a real-time scenario, it is only expected that the chain will extend to Debtor/Creditor and one Intermediary Agent (as a maximum). Page 2 ISO 20022 RTPG Message Flows

  3. Real-Time Payments: Message Portfolio OVERLAY SERVICES DEBTOR CREDITOR INTERBANK MESSAGING pain.001/002 pain.013/014 camt.052/053/054 camt.056/029 remt.001/002 pain.013/014 camt.052/053/054 camt.056/029 remt.001/002 pain.013/014 pacs.004 camt.056/029 remt.001/002 pacs.008 pacs.002 vvv Core Payment messages ORCHESTRATION MESSAGES* Optional usage and driven by system design and market usage SETTLEMENT MESSAGES pacs.009 pacs.010 * The ISO 20022 catalogue offers a vast range of orchestration messages 3 ISO 20022 RTPG Message Flows

  4. *Flow #1: BASIC CUSTOMER CREDIT TRANSFER FLOW (The Happy flow) 1. The Debtor initiates a credit transfer to the Debtor Agent, using a pain.001 or similar message. 2. Based on the credit transfer initiation message, the Debtor Agent sends a pacs.008 to the MI which sendson the message to the Creditor Agent. 3. The Creditor Agent validates the pacs.008 and sends a positive pacs.002 back to the MI to confirm that the message was valid. 4. The MI then delivers a pacs.002 to the Debtor Agent and to the Creditor Agent to advise that the transaction has been completed. 5. Upon receipt of the pacs.002 from the Central Switch, the Debtor Agent will notify the Debtor and the Creditor Agent will notify the Creditor that the Transaction was successfully completed. CREDITOR AGENT DEBTOR CREDITOR DEBTOR AGENT MI Clearing Payment initiation Clearing Cash Management 1 PACS.008 2 PACS.008 2 3 PACS.002 3 PACS.002 PACS.002 4 4 [Note: this basic flow will repeat in most process flows depicted within and as such shall be identified as Flow #1] 5 5 ISO 20022 RTPG Message Flows Page 4

  5. Flow #2: Rejection By Creditor Bank (Account Closed) (An Unhappy Flow) DEBTOR AGENT CREDITOR AGENT DEBTOR CREDITOR x Account Closed 1. The Debtor initiates a credit transfer initiation message, using a pain.001 or similar message, to the Debtor Agent. MI Clearing Payment initiation Clearing Cash Management 2. Based on the credit transfer initiation message, the Debtor Agent sends a pacs.008 to the MI which then sends the message to the Creditor Agent. 1 PACS.008 2 PACS.008 2 3 3. The Creditor Agent conducts the necessary checks and notices the Creditor account is closed. The Agent will reject the pacs.008 by sending a negative pacs.002 with the appropriate reason code for rejection to the MI. PACS.002 3 PACS.002 4 4. The MI will then deliver a pacs.002 to the Debtor Agent to advise that the transaction was not completed. 5 Note: Account Closed is one of a number of reasons a transaction may be rejected. ISO 20022 RTPG Message Flows Page 5

  6. ISO 20022 RTPG Message Flows Flow #3: Pain.013 and pain.014 (Optional Service) 1. The Creditor initiates the request for payment to the Creditor Agent (using a pain.013 or similar message). 2. The Creditor Agent will initiate a pain.013 message directly or via the MI to the Debtor Agent. 3. The Debtor Agent notifies the Debtor of the payment request and responses in accordance with the scheme rules. 4. In the event of a negative response, a need to provide information, or a change in the payment details, the Debtor may respond using a pain.014+ (or similar message) to the Debtor Agent with appropriate response included. 5. The Debtor Agent delivers the response to the Creditor Agent, directly or via the MI, using a pain.014. 6. The Creditor Agent notifies the Creditor of the Debtor s response as appropriate using the pain.014 or similar message. 7. In the event of a positive response, the Debtor may initiate a payment instruction to the Debtor Agent* and a process flow largely in the form of Flow #1 shall take place. CREDITOR AGENT DEBTOR CREDITOR DEBTOR AGENT MI Clearing Payment initiation Clearing Cash Management 1 PAIN.013 2 PAIN.013 2 3 4 PAIN.014 5 PAIN.014 5 + Pain.014 should be used to provide a negative response to a pain.013 or an amendment to the pain.013. * This step is dependant on the service offerings of the Debtor Agent. Usually the Debtor Agent would create the pacs.008 as a service to its client. 6 ISO 20022 RTPG Message Flows Page 6

  7. ISO 20022 RTPG Message Flows Flow #4: REMT.001 and REMT.002 (Optional Service) The corresponding Flow #1 may be initiated at any time before, during or after this process. CREDITOR AGENT DEBTOR CREDITOR DEBTOR AGENT 1. The Debtor may also deliver a Remittance Advice or a Remittance Location Advice message, using a remt.001/002 or similar messages, to the Debtor Agent (or, to another service provider or directly to the Creditor) MI Clearing Payment initiation Clearing Cash Management 1 REMT.001 or 002 2 REMT.001 or 002 2 2. The Debtor Agent (or other service provider) delivers the remt.001/002 message to Creditor Agent (or the Creditor) 3 3. The Creditor Agent also delivers the Remittance Advice and Location Advice messages (if applicable) to the Creditor * The remt.001 may or may not follow the same route/channel as Flow #1 and will contain Identification and Location information. It can also be made available in a Remittance Database/Repository. Page 7

  8. ISO 20022 RTPG Message Flows Flow #6: Cancellation Request, Request for Return of Funds and Resolution of Investigation (Optional Service) A cancellation request or a request for return of funds would be initiated following Flow #1. 3. After a period of time, upon instruction from the Debtor or in accordance with agreements, the Debtor Agent delivers a payment cancellation request using a camt.056 seeking to return (cancel) the initial pacs.008 payment. The Creditor Agent upon receipt of the camt.056 will await a response from the Creditor to return (cancel) the payment. 4. The Creditor Agent shall respond to the cancellation request by delivering a Resolution of Investigation message (camt.029) in the event of a negative or positive response to the request for return (cancelation). 5. Depending on the framework, in the event of a positive response, the Creditor Agent may also issue a pacs.004 or 008 depending to return the payment, to the Central Switch which sendson the message to the Debtor Agent. 6. The Central Switch will then deliver a pacs.002 to the Debtor Agent and to the Creditor Agent to advise that the transaction has been completed. 7. Upon receipt of the pacs.002 (optional) from the Central Switch, the Debtor Agent will notify the Debtor and the Creditor Agent will notify the Creditor that the Transaction was successfully completed. CREDITOR AGENT DEBTOR CREDITOR DEBTOR AGENT MI Clearing Payment initiation Clearing Cash Management 3 CAMT.056 CAMT.056 3 2 CAMT.029 4 CAMT.029 4 PACS.008/004 5 PACS.008/004 5 PACS.002 6 PACS.002 6 7 7 * In a real-time environment, the camt.056 is being used more and more as a Request for Return of a payment that has already been settled.

  9. ISO 20022 RTPG Message Flows Settlement Models 1. Deferred Net Settlement 2. Real Time Settlement 3. Hybrid Settlement ISO 20022 RTPG Message Flows 9

  10. ISO 20022 RTPG Message Flows SETTLEMENT MODELS DEFERED NET SETTLEMENT MODEL Description: Model where real time transactions are settled in batches on a net basis at the end of a pre-defined settlement cycle or more than once per day. This settlement system requires collateralized participation Advantages: Reduction in stress to the settlement system Saves on the liquidity for participants Disadvantages: Overnights and weekends are typically high credit risk times for participants Posting transactions before they are settled also creates credit risk and liquidity costs Usages: China, Denmark, India, Japan, Singapore, South Korean, South Africa and UK ISO 20022 RTPG Message Flows 10

  11. ISO 20022 RTPG Message Flows SETTLEMENT MODELS Cont d REAL TIME SETTLEMENT Description: Real-time settlement: the immediate or near immediate settlement of each real time transaction exchanged between an originator and receiving entity Settlement occurs at the Central Bank in real time Typically requires participants to maintain prefunded settlement accounts at the Central bank to ensure adequate funding for transactions. Advantages: Minimal/no settlement system Minimal/no credit risk Disadvantages Highest in liquidity costs for participants Complex liquidity management Inaccessible to smaller FIs, due to high liquidity cost Country Usages Canada, Sweden, Poland, Australia, and TCH ISO 20022 RTPG Message Flows 11

  12. ISO 20022 RTPG Message Flows SETTLEMENT MODELS Cont d HYBRID SETTLEMENT SYSTEMS Description: Hybrid settlement systems combine the characteristic of real time settlement and deferred net settlement systems This settlement system support centralized queuing, payment prioritization and reduces payment delays Advantages: Minimal/no participant default risk Minimal/no credit risk Disadvantages Higher liquidity costs for participants Liquidity and risk management through setting value limits Country Usages Brazil, Thailand, Philippines, Peru and Mexico ISO 20022 RTPG Message Flows 12

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#