Is a pacs.008 REST API sufficient?

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 CPG.classic also offers the option of triggering payments via a REST API:

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren

However: 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)
• Amount

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)
• Recall (see camt.056 ISO 20022 Message, camt.029 ISO 20022 Message)
• Inquiries

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!