Independent SCT Inst processing with real-time sub-ledger

Published on


Reading time

3 min

SEPA Instant Payments (SCT Inst) will most probably become mandatory for banks in the EU in the foreseeable future. Whether these real-time transactions will lead to higher revenues in payment traffic is certainly doubtful. For the institutions, SCT Inst will therefore only be a hygiene factor and not a new source of income. Nothing is therefore more obvious than to fulfil the obligation as cost-effectively as possible, as described below.

Initial Situation

Contrary to popular belief, real-time systems in payment processing are more of a step backwards than a step forward for banks (see article on liquidity management).
In order to handle retail payments robustly and cost-effectively, message formats and communication channels are designed for batch processing. Some core banking systems (CBS) are simply not fast enough to handle many, simultaneous real-time transactions and often have booking runs that get in the way of the required 24/7 operation.

A CBS exchange is associated with great effort and a high project risk, so the use of an independent subsystem for SEPA Instant Payments is an alternative worth considering.

The Challenges of SCT Inst

The SEPA rule books for instant payments differ from the conventional SEPA credit transfer in three essential points:

  • the transaction must be possible around the clock
  • the transaction must be completed in 10 seconds and
  • there is a positive transaction confirmation (pacs.002) as well as supplementary message formats (R-transactions).

If as little as possible is to be changed in the existing CBS, a subsystem must solve the requirements of SCT Inst.

24/7 and Real Time Processing

If a core banking system itself is too slow or unavailable for a longer period of time due to internal booking runs, nothing helps but to operate a parallel booking system for SCT Inst. Both unexpected (shorter) disruptions and scheduled (longer) downtimes can be bridged if the disposition of payments takes place in a sub-ledger.

SEPA Instant Payment SubsystemThe CBPay Instant Module is “passively” integrated into the bank’s payment transactions and “eavesdrops” on all transactions. Incoming and outgoing SEPA Instant Payment transactions are filtered out and executed by the module, while all other transactions are checked for their booking relevance. Based on this data, a sub-ledger is kept that ensures the processing of instant payment transactions in the event of a failure of the core banking system.

Umgang mit SCT Inst Nachrichtenformaten

In a smaller variant of the CBPay Inst module, the existing core banking system is “preserved” from the SEPA Instant Payment specific message formats. The prerequisite for this is that the CBS is generally real-time capable and only small disruptions have to be bridged.
The most important example of this is the positive confirmation (pacs.002) of a payment, which does not occur in SEPA retail payments.
Less frequent, but still necessary, is the handling of the various R-transactions, e.g. incoming queries and enquiries.
The camt.005/6 was introduced completely new with Instant Payments: a camt.005 is used to enquire about the whereabouts of a payment and the camt.006 is the corresponding answer. However, this response does not contain the original account information. To make the message processable for the CBS, information from the original pacs.008 is used to create a “conventional” pacs.002:

  • A camt.006 with status SETTLED is converted into a pacs.002 ACCP
  • A camt.006 with status EXPIRED or similar becomes a pacs.002 RJCT

Connection to TARGET Instant Payment Settlement (TIPS)

Medium-sized and small banks usually prefer a connection to TIPS for cost reasons. This is often done via SWIFT as a network service provider for ESMIG, because there is a business relationship with SWIFT anyway. As a certified SIA (nexi Group) partner, CPG also enables its clients to connect to ESMIG via SIA as an alternative Network Service Provider. In a cost-efficient variant, an SIA/nexi account is shared among several participants. Of course, it is possible to switch to a dedicated account if required, so that a favourable entry can be made without limiting later growth.

We will be happy to answer your questions. Please use our contact form.

Are you looking for a solution for electronic payments?