Receiving bank processes recall request

The upper right section of the recall/return flow diagram shows how the receiving bank receives recall requests. The recall/return flow for the receiving bank does the following when it processes a recall request:

  1. STEP2 places a settled credit file (SCF S202SCTSENDBANKF056A) that contains the camt.056 recall requests for the receiving bank onto Q3. The credits that are mentioned by the recall must already have been recorded by the receiving bank.
    Note: Because a STEP2 simulator is being used, the SCF is not generated automatically. Instead, an SCF containing the camt.056 recall requests needs to be built manually:
    1. Stop the ICFToCVF simulator flow in the simulator BAR file before the recall requests for the sending bank are bulked.
    2. The ICF containing the camt.056 messages from the sending bank will be left on Q2.
    3. Find and edit this ICF. Copy the S202SCTSENDBANKF056A messages to the clipboard.
    4. Using the message template called 02 S202SCTSENDBANKF056A.S, create a new SCF file.
    5. Paste the copied messages into the new SCF file and save it.
    6. Place the new SCF onto Q3.

    These steps can also be used to create an SCF file when demonstrating the system.

  2. Settled credit transfers appear as payment transactions with a subtype of CT_IN_S2 on the FTM Operations and Administration Console (OAC) of the receiving bank. This is shown in the following figure.
    Figure 1. Recall/return flow: receiving bank receives the recall request as a settled credit transfer
    fxjSctSettledTransfer.jpg
  3. The receiving bank processes the individual camt.056 recall messages it received in the SCF(S202SCTSENDBANKF056A) bulk. Each request appears as a payment transaction with a subtype of payment cancellation request (from STEP2) and a status of awaiting operator verification. The following figure shows the transaction awaiting verification highlighted in yellow.
    Figure 2. Recall/return flow: receiving bank operator receives a cancellation request
    fxjSctCancelWait4Op.jpg
  4. An operator alert is produced for each recall request. Users of the OAC at the receiving bank check for, and respond to, alerts that indicate there is a recall request pending.
  5. The operator at the receiving bank responds to the alert by:
    1. clicking the payment transaction row to select it.
    2. clicking the Resolve button, which looks like a pinwheel.
    3. choosing the verify action.
    The alert is cleared from the alert screen. The status of the payment transaction with a subtype of payment cancellation request (from STEP2) is changed to inbound txn awaiting operator accept/reject as shown in the following figure.
    Figure 3. Recall/return flow: receiving bank operator clears alerts
    fxjSctInboundTxnWait4Op.jpg
  6. Using the OAC, the receiving bank operator can only reject a recall request. Accepting a recall request requires the user to access information that is not controlled by the OAC. The recall/return flow for the receiving bank continues with whether the receiving bank accepts or rejects the recall request from the sending bank.