Main flow: Creditor processes a direct debit request

The following figure shows only the creditor side of the flow. Use the instructions to prepare messages and execute the creditor direct debit flow. The flow diagram contains numbered reference points that are used by the instructions.

The following steps describe how to use the SDD reference application to demonstrate debit request processing. Included with the step-by-step processing instructions is additional information about debit processing and the way that the SDD reference application operates.

1. The instructions for this step correspond to reference point 1 on the flow diagram in Figure 1.
   1. Clear the FTM database. It is advisable to start with a clean system to easily follow the processing of the debit request.
   2. Make sure that the Integration Bus is started and that the BAR files are deployed.
   3. Locate the SDD Test Files project in the Integration Toolkit workspace. This is where the test messages for each of the scenarios are located. This project has separate folder structures for the creditor and debtor messages.
   4. Edit the FTM SDD Test Data/Creditor/Debit Request/COR1_pacs003_RB6.xml file and change the dates in the IntrBkSttlmDt and ReqdColltnDt tags to a date two business days in the future. Save the file.
   5. Using a utility that can post messages to MQ queues, post this message to the queue named Q1 (FXJ.SDD.CLIENT.IN.PACS003).

   The application evaluates the dates, scheme, and the type of each debit request. STEP2 specifies allowable date offsets from the current date for acceptance of debit requests. See the STEP2 specifications for these date offsets, which depend on the scheme of the debit request (CORE, COR1, or B2B) and the type of debit request (one-off, first of recurring, or recurring).

   The application rejects a request if it is too late to be processed by STEP2. The system will not reject a request for being too early, even though STEP2 may not accept it for a while. The application holds onto debit requests that are too early until such time that they will be accepted by STEP2.

2. This step corresponds to reference point 2 on the flow diagram in Figure 1.

   Editing the pacs.003 test file shows that it is a batch containing five debit requests. The SDD reference application can process batches of requests, but the SEPA credit transfer reference application does not presently process batches of pacs.008 credit transfer requests.

   Posting the pacs.003 message causes it to be consumed by the FTM creditor. It is mapped to the ISF format and stored in the FTM database. The SDD reference application creates transactions that are used to track the life cycle of the debit request.

   After the pacs.003 file is processed, use the FTM Operations and Administration Console (OAC) to view the payment transactions. The following figure shows that the message that was ingested is a batch debit transaction that contains five debit requests.

   

3. The following processing steps have to occur before debits are posted to STEP2:
   1. StartSubmissionDateProcessing: During submission date processing, the dates that are recorded in the debit requests in the system are evaluated. Depending on the type of debit request, the date in the debit request, and the current date, the system selects debit requests that are in the allowable time frame for transmission to STEP2. This selection is recorded by changing the status of the transaction from Waiting for Submission Date Processing to Waiting to be Bulked.
   2. StartDDBulk: After submission date processing, StartDDBulk is used to bulk and send the debit requests to STEP2. Bulking is a term that means combining many files into a single file for transmission to STEP2.

      Submission date processing ensures that debits marked Waiting to be Bulked are date-eligible for processing by STEP2. The bulking process gathers all such debits and bulks them for transmission to STEP2. Debits that were received, but not date-eligible, are retained and are bulked when they become date-eligible.

      Since XML is used for the messages, bulking is done by forming an XML file that wraps the messages to be bulked within an enclosing root tag. The SDD reference application only produces a single bulk file type, input debit file (IDF), which wraps various pacs and camt messages for transmission to STEP2.

   These processing steps can either be invoked manually using the OAC or be executed on a scheduled basis by the application.

4. There are currently five debit transactions that need to be processed. To manually perform submission date processing and bulking, the IDF consumer is used. To display the actions available for the IDF consumer:
   1. Use the OAC to display the list of service participants. Locate and select the IDF consumer in this list as shown in the following figure.

      

   2. Click the IDF consumer to open the Service Participant Details window.
   3. Click the pinwheel icon, as shown in the following figure to display the resolve actions that are provided for the IDF consumer.

      

   4. The drop-down list on the details window, shown in the following figure, lists the resolve actions that are available for the IDF consumer. The actions for a creditor processing debit requests are StartDDBulk and StartSubmissionDateProcessing. The StartSettlementDateProcessing action is used by the debtor bank.

      

5. Select StartSubmissionDateProcessing from the list, enter a comment, and click the green arrow on the bottom right of the window. This causes submission date processing to occur for the five debits in the batch that was submitted. This step corresponds to reference point 3 on the flow diagram in Figure 1.

   Submission date processing changes the status of the five transactions to Outgoing Txn Waiting to Bulk as shown in the following figure.

   

6. Repeat steps 4.a to 4.d to display the actions for the IDF consumer. This time, choose the selection StartDDBulk from the list. This step corresponds to reference point 4 on the flow diagram in Figure 1.
7. Bulking causes the five transactions that are waiting to be bulked to be combined into a single XML message. The five messages are wrapped in an input debit file (IDF) root tag. The IDF message is defined according to the EBA schema definitions that were added to a message set during installation. After the IDF is created, the SDD reference application posts it to queue Q2 for consumption by a simulator flow. This step corresponds to reference point 5 on the flow diagram in Figure 1.
8. This step corresponds to reference point 6 on the flow diagram in Figure 1.

   The simulator flow that processes the IDF messages produces a response message called a debit verification file (DVF). The DVF produced by the simulator accepts all of the debit transactions contained in the IDF to which it is responding. This DVF is posted by the simulator flow onto queue Q5.

   If the simulator flow is allowed to run, a positive response is generated for all contents of every DVF. If the DVF is built to reject some or all of the transactions contained in the IDF, the simulator flow named PartnerSimulator.IDFToDVF can be stopped as shown in Figure 7.

   

9. At this point, the simulator does not supply a response, and a DVF message can be created manually. Post the DVF message to Q5 to provide the response to the application. To build a DVF message, refer to some of the test messages provided, such as DVF1_Reject.xml, as an example of creating a DVF file. Also, use the EBA schema files to ascertain the detailed format and content of the DVF file that will be built.
10. After bulking is done and the DVF is received from STEP2, more transactions are recorded and the status of the prior transactions are updated. Figure 8 shows the OAC Payment Transaction list after the DVF is received. This step corresponds to reference point 7 on the flow diagram in Figure 1.

    

11. The last six records in Figure 8 pertain to the DVF and acknowledgments that have been posted back to the original client that sent the pacs.003 debit request. These are marked complete, which is indicated by the green dot at the left. The transaction with subtype Inbound Debit Validation File corresponds to the receipt of the DVF from STEP2.
12. The final five records in Figure 8 have a subtype of Outbound Direct Debit Acknowledgment and correspond one-to-one with the five debit transactions that were batched in the initial pacs.003. These final five records are pacs.002 status messages generated by the application. They are posted back to the original client using queue Q10 (FXJ.SDD.CLIENT.OUT.PACS002). This step corresponds to reference point 8 on the flow diagram in Figure 1.

    Use MQ Explorer to look at the queue corresponding to Q10. There are 5 messages on it. These are the pacs.002 status acknowledgment messages.

13. The pacs.002 status messages inform the originator of the pacs.003 message about the status of the debit requests. All messages posted to Q10 are to be consumed by the client who originated the debit requests to the creditor financial institution. This step corresponds to reference point 9 on the flow diagram in Figure 1.
14. The instructions for this step correspond to reference point 10 on the flow diagram in Figure 1.
    1. The debit requests have been received by STEP2, but settlement has not yet occurred. Verify this on the creditor OAC by viewing the status of the transactions for the inbound and outbound direct debits, which all indicate that they are waiting for settlement.
    2. Before settlement can occur, STEP2 needs to send the debit requests to the debtor bank. The interaction between STEP2 and the debtor bank is described in the main debtor flow.
    3. After STEP2 notifies the debtor bank of the debit requests, EBA settlement occurs.
    4. During the STEP2 business day, STEP2 sends a results of settlement file (RSF) message to all creditor and debtor financial institutions. The SDD reference application processes this file and updates the status of debit transactions.
    5. Post any message to Q6 to simulate STEP2 creation of the RSF message. The message on the queue is discarded, but it causes the simulator to produce an RSF message indicating that settlement has occurred for all unsettled work in the FTM database.
15. The STEP2 simulator generates an RSF message and posts it to Q11. This step corresponds to reference point 11 on the flow diagram in Figure 1.
16. The SDD reference application for the creditor processes the RSF message. The transactions in the RSF that were settled have their status updated to show that they were settled successfully. The RSF message is also mapped into internal standard format (ISF) and stored in the FTM database. This step corresponds to reference point 12 on the flow diagram in Figure 1.

    After the RSF message is processed, the OAC displays the status as shown in Figure 9.

    

    The status of the debit transactions now shows that they are settled and waiting for completion.

17. To complete the settlement process, a daily reconciliation report (DRR) message is sent by STEP2. The SDD reference application uses this as a signal that the STEP2 business day has completed. The instructions for this step correspond to reference point 13 on the flow diagram in Figure 1.
    1. Post any message to Q7 to cause the STEP2 simulator to generate a DRR message and post it to the reference application on Q8.
18. The STEP2 simulator generates and posts a DRR to Q8. This step corresponds to reference point 14 on the flow diagram in Figure 1.
19. The SDD reference application for the creditor processes the DRR message. The transactions in the DRR that were completed have their status updated to show that they were settled and completed successfully. The DRR message is also mapped into internal standard format (ISF) and stored in the FTM database. This step corresponds to reference point 15 on the flow diagram in Figure 1.
    After the DRR message is processed, the OAC displays the status as shown in the following figure.

    

20. The status of the debit transactions now shows that they are complete.