An article by
Not much information is required to initiate a payment. It must seem easy to trigger a pain.001 (format for corporate customers) or pacs.008 (interbank payments) with a REST API. Of course, our payment system CBPay also offers the option of triggering payments via a REST API (see video live demo). Unfortunately, this is not enough for a German SEPA member bank and this article explains why a pacs.008 REST API alone is not very useful.
Information required for a SEPA credit transfer – pacs.008 REST API
For corporate customers, the format for transfers is pain.001 in accordance with ISO 20022. In interbank payments, it becomes a pacs.008 with identical information.
The minimum information for a credit transfer is:
- Debtor name
- Debtor IBAN
- Debtor BIC (can be calculated from IBAN)
- Creditor name
- Creditor IBAN
- Creditor BIC (can be calculated from IBAN)
The intended use (remittance info) and an “end to end ID” must also be transmitted as a field, but the content is not checked. As long as the payment is processed with the SEPA Clearer (retail payments interface of German Bundesbank), the currency is clear today: Euro. However, if the payment is processed via SWIFT, information on the currency is mandatory.
In the case of international payments, there are also mandatory ( EBA wire transfer regulations) address details for sender and recipient. The number of fields required for a pacs.008 REST API therefore depends on the intended use.
A credit transfer is not enough
The standard case “transfer” when processing with the SEPA Clearer of the Bundesbank with EBICS actually does not result in any follow-up transactions or reply messages. However, the Bundesbank requires proof of handling exceptional cases:
- Rejection of the transaction by the recipient bank (e.g. account expired)
Particually the inquiry “clain for value date corretion” requires many information about fees and date. A detailed description of the message dialog for SEPA credit transfers can be found in this article about SEPA SCT formats.
A pacs.008 REST API would need more than 50 fields to handle all related message formats.
How does an exemplary concept for payment systems connection look like?
The accumulation of data fields from different Iso 20022 message formats in a REST API inevitably leads to a high maintenance effort for the payment system interface. In order to limit changes, it is advantageous to divide the channels into SDD, SCT and camt. Whether and how a core banking system then handles the individual messages can be individually adapted with modern payment systems like CBPay.
In any case, ignoring messages is not a recommended option!