Creditor FI Outgoing Request for Payment (TCH)
The main Creditor FI Outgoing Request for Payment flow.
Use case summary
The Request for Payment is initiated by a (creditor) client who requires payment from a debtor. The request is delivered by the creditor financial institution (FI) to the clearing and settlement mechanism (CSM). The CSM delivers the request to the debtor FI, who can pass the request to their (debtor) client.
Having delivered the Request for Payment request to the CSM, the creditor FI times out if it does not receive a status confirmation from the CSM within the defined period. At this time, it re-sends the request with a possible duplicate flag, continues waiting for the status confirmation, and, possibly, re-sends again after further time outs. An option is provided for operations to manually cancel the request. This would normally only be used in the case of a prolonged outage of communication to the CSM, when it can also be confirmed that the request was never delivered to, and processed by, the CSM.
- FTM The Clearing House Real Time Payments receives a request from the channels interface on behalf of a (creditor) client to initiate a Request for Payment.
- The request is validated by being checked for duplicates.
- If the previous step is successful, the set of services that are configured for the pre-check set are invoked.
- If the pre-checks are successful, a Request for Payment request is sent to the CSM.
- FTM The Clearing House Real Time Payments then waits for the confirmation status message from the CSM.
- If the status message is not received within a defined timeout limit, the creditor FI times out and re-sends the request with a possible duplicate flag to the CSM, restarts the timer, and continues waiting. This step can repeat until either a status confirmation is received from the CSM or the operator cancel is issued.
- Next, FTM The Clearing House Real Time Payments sends an acknowledgment to the channels interface, which, in turn, may provide a notification to the (creditor) client.
- The transaction will then wait for a Request for Payment Response to be received and will finish up in an 'RFP Accepted' state (on receipt of a camt.029 accept) or an 'Amounts matching' or 'Amounts not matching' state depending on the response message content. The RFP can expire while waiting for a response if an expiry value is contained in the message. If the message is moved to an 'RFP Accepted' state then it can no longer expire. The operator can also cancel the Request for Payment via the OAC while the transaction is waiting for a response.
- The Request for Payment Response total amount will be stored as a counter against the Request for Payment transaction: TYPE = 'IP_CORE', NAME = 'TOTAL_PAYMENTS', which keeps track of a count of the number of responses (payments) made for the request, and a total of the amounts of these responses. The Request for Payment transaction will transition to an 'Amounts matching' or 'Amounts not matching' depending on this total.
Use case high-level sequence diagram
Use case detailed sequence diagram
FTM The Clearing House Real Time Payments, which is represented by one lifeline in the preceding high-level sequence diagrams, has been divided into multiple lower level lifelines in the following series of sequence diagrams. The lower level lifelines are grouped together by yellow boxes.
| Referenced interaction | Reference link |
|---|---|
| Log and Map Single Txn | Log and map single transaction diagram |
| Inline Send Txn (Expect Ack) | Send transaction expect acknowledgment diagram |
| Inline Send Txn (Fire and Forget) | Send transaction fire and forget diagram |
Use case simple object lifecycle diagram
