Creditor FI incoming request for recall - good and bad

The main creditor FI incoming request for recall flow.

Use case summary

The request for recall can be initiated by a (debtor) client, or a debtor financial institution (FI) to request the return of a payment that was sent in error. The request is delivered by the debtor FI to the clearing and settlement mechanism (CSM). The CSM delivers the request to the creditor FI, who can pass the request to their (creditor) client.

The creditor FI incoming request for recall case consists of the following processing steps:
  1. FTM for High Value Payments receives a request either from the CSM or created as part of an on-us payment cancellation request process.
  2. The request is validated, checked for duplicate, and correlated to the original payment.
  3. If the validation step fails, a response to recall (reject) is sent back to the CSM. Or, if a duplicate is detected the transaction moves to an alert state, waiting for operator verification.
  4. If the validation step is successful, the services that are configured for the precheck set are started.
  5. If the precheck services did not complete successfully, the process is completed by setting a failed status, and a response to recall (reject) is sent back to the CSM.
  6. Following successful completion of the precheck services, the services that are configured for the post-accept set are started.
  7. The default for the configured post-accept service is to send a notification to the channel interface, which might provide a notification to the (creditor) client. However, this function can be overridden by configuration so that the notification is not sent. You can configure whether a notification is sent and to which channel it is sent by using VALUE table entries as described in the following list.
    • To configure whether a notification is sent, you need to determine which category that you want to control sending notifications for. The category to use is the service participant rank that is linked to the correlated payment, which is captured in the SCHEME of the recall object, followed by the text _CHANNEL_CONFIG. For example, TARGET2_CHANNEL_CONFIG. This category along with the CHANNEL_SEND_NOTIFICATION_RCL key determine whether the notification is sent to the channel or not. By default, the CHANNEL1_CHANNEL_CONFIG category is used to determine whether notification is sent.
    • The channel to which the notification is sent is determined by the object value entry where the category is HVP_CORE and the key is NOTIFICATION_DESTINATION. The value that is returned is the notification destination that is set during validation, and matches the value set for the correlated payment. The returned value is matched to a service participant entry with a matching rank and the outbound channel is used for notification.
    • For uncorrelated requests for recall, the notification channel is determined by the configuration entry where the category is SCHEME_CONFIG and the key is DEFAULT_RCL_NOTIFICATION_DEST. An example of a category for these requests is TARGET2_CONFIG. The returned value is matched to a service participant entry with a matching rank and the outbound channel is used for notification.
  8. After the post-accept services complete, FTM for High Value Payments waits until a response to request for recall (resolution of investigation) related to this request was processed before the process is completed.
  9. During the wait for the process to complete, an operator command might be received. The command causes the initiation of a response to request for return of funds that, depending on the command, either accepts or rejects the request.

Use case high-level sequence diagram

The high-level sequence diagram for the creditor FI incoming request for recall use case is shown in the following figure.
Note: The diagram illustrates a set of optional services within a parallel group for the precheck service set. This group is empty as no services are configured by default. The set is provided as an extension point for customization.
Figure 1. Creditor FI incoming request for recall - high-level sequence diagram
fxtfnctcreditorincomingrequestforrecallhighlevel.png

Use case detailed sequence diagram - good

The detailed sequence diagram for the creditor FI incoming request for recall good use case is shown in the following figure.
Figure 2. Creditor FI incoming request for recall - good
fxtfnctcreditorincomingrequestforrecalldsd1.png

Use case detailed sequence diagram - bad

The detailed sequence diagram for the creditor FI incoming request for recall bad use case is shown in the following figure.
Figure 3. Creditor FI incoming request for recall - bad
fxtfnctcreditorincomingrequestforrecallbaddsd1.png

Use case simple object lifecycle diagram

The simple object lifecycle diagram for the creditor FI incoming request for recall use case is shown in the following figure.
Figure 4. Creditor FI incoming request for recall
fxtfnctcreditorincomingrequestforrecallold1.png