General
SEPA Payment Suite can manage the following types of banking reports:
Payment Status Report (format pain.002): File acknowledgement (ARA [accusé de réception applicatif]) provided by banks in response to collection files or reject notices that may contain rejects from the compensation system or debtor bank, refusals by the debtor or returns/refunds received;
Debit Credit Notification (format camt.054): operational statement provided by creditors’ banks to inform them of the payment of direct debits and outstanding payments.
Bank to Customer Statement (format camt.053): operational statement provided by creditors’ banks to inform them of the payment of direct debits and outstanding payments.
These reports are described in the product interfacing document. Other specific formats can also be implemented at the request of the client.
SEPA Payment Suite analyses these files in order to manage the lifecycle of each corresponding transaction and create R-transactions if necessary. The system allows this information to be uploaded to creditors in a number of ways.
Lifecycle of R-transactions
The following diagram summarises the different stages of an R-transaction within the application:
Picture 10: Lifecycle of R-transactions
Management of acknowledgements of receipt and reject notices
SEPA Payment Suite uses status reports to update the status of collection files, collections and transactions. The connection between the report data and the system data is based in particular on references from these data.
The system can manage the 3 levels of bank rejection:
File rejection: the original collection file as well as the collections and transactions contained within this are updated to “Rejected”;
Collection rejection (total or partial): in the event that the entire collection is rejected, the statuses of the collections sent by the creditor as well as the transactions contained within are updated to “Rejected”. In the event that only part of the collection is rejected, its status is changed to “Partly rejected” and the transactions contained within it are updated according to the information provided within the report (see point below);
Transaction rejection: depending on the information provided within the report, the transactions are updated to “Rejected”, “Settled” or “Returned” within the system.
The system links the rejection reason to the rejected collection file, collections and/or transactions. The rejection reason is visible on the application’s GUI. In addition, for each rejected transaction, an R-transaction is created and attached to the original order. In the event that an R-transaction refers to unknown SEPA Payment Suite flow, the R transaction is not recorded within the database.
If the SDD is already in a status rejected, the R transaction is created under the status “Waiting for diagnostic”.
The system takes into account that several status reports may be provided by the bank: technical acknowledgement of receipt and/or functional acknowledgement of receipt. It is therefore possible to change a “Settled” status to a rejected status. In the case of “functional” acknowledgement but also rejection of transactions, SPS fill the Transaction fields Value Date and Settlement Date with the values indicated in the report files.
Management of operational reports
SEPA Payment Suite uses these bank reports to update the status of transactions when they contain outstanding payments. “Rejected” if the initial transaction has not yet been paid; otherwise “Returned”. The reject instruction is also registered in the database in the form of an R-transaction with the status “Settled” and is compared to the initial transaction.
The connection between the report data and the system data is based in particular on the end-to-end reference of these orders. In the event that an R-transaction refers to unknown SEPA Payment Suite flow, it is recorded within the database with the status “Waiting for diagnostic”.
Figure 42 - Rtransaction reception process
Reasons for rejection
One of the rejection reasons specified by the following EPCs is added to each rejected SDD:
(Debtor’s) account number incorrect;
Account closed;
Account blocked/Account blocked for direct debit by debtor;
Direct debit forbidden on this account for regulatory reasons;
Invalid bank operation code;
Insufficient funds;
Duplicate;
Name of debtor/name of account owner not identical;
Incorrect file format;
No mandate;
Mandate not valid;
Authorised transaction disputed;
Debtor deceased;
Refusal by debtor;
Reason not known;
Invalid BIC;
Regulatory reason;
Specific service offered by the debtor’s bank.
Returning R-transactions to the creditors
SEPA Payment Suite offers 3 ways to return R-transactions to the creditors:
-
via a file transfer in a given format (pain.002/camt.054/camt.053)
-
via the application GUI: the R-transaction search and viewing screens are made available to users. An R-transaction is visible via the SDD flow to which it relates; Users can also create R-transactions when updating transactions status to rejected/returned.
-
via a domestic file report generated (CFONB240, DOM80) summarizing the information found in the SEPA XML files from the bank
- If the return file contains a bank account with a BIC8, the application checks in bank accounts of the organization if there is an account with the same IBAN and with a BIC11 containing the BIC8.