Creditor FI Incoming Credit Transfer Good
The main Creditor FI Incoming Credit Transfer flow.
Use Case Summary
The creditor FI incoming credit transfer good case consists of the following processing steps:
- FTM for Immediate Payments receives a payment from the CSM.
- The payment is validated and checked for duplicate.
- Next, the set of services that are configured for the Pre-Check set are invoked. This set should just perform validation checks to determine whether the payment can be accepted.
- On successful completion of the Pre-Check services, the set of services (if any) that are configured for the Pre-Accept set are invoked.
- On successful completion of the Pre-Accept services, FTM for Immediate Payments sends a positive acknowledgment to the CSM, confirming that the payment has been accepted by the bank.
- FTM for Immediate Payments optionally waits for an acknowledgement status message from the CSM. In the case of TCH this status message is expected. In the case of SCT Inst this status message is not mandated by the EPC rulebook so, depending on the CSM, it may not be expected, in which case this step can be configured to be omitted.
- FTM for Immediate Payments performs a position update for the current settlement cycle (not implemented yet) and invokes the services configured for the Post-Accept set. This will typically include a service to send a notification to the Channels interface, which in turn may provide a notification to the (creditor) client.
- (Optional, TCH) If the payment contains a reference to a related Remittance Advice message, FTM for Immediate Payments will wait for and correlate with this related remittance transaction, before the payment proceeds to the completed state.
Use Case High-Level Sequence Diagram
The high-level sequence diagram for the creditor FI incoming credit transfer good case looks as shown in
the following figure:
Note: The diagram illustrates sets of optional services within parallel groups for each
of the service sets Pre-Check, Pre-Accept, Post-Accept. The services shown depict services that may typically
be included in the set. The actual services to be invoked, and whether they are invoked in parallel or
serially is determined by configuration
Use Case Detailed Sequence Diagram
The detailed sequence diagram is split into three parts.