Swiss Instant Payments - burden or opportunity for banks?

The payments landscape has been undergoing significant changes for years. This trend will accelerate considerably in the coming years, driven by a) increased customer expectations (retail and corporate), b) regulation as well as c) increasing competitive pressure (neo banks, FinTechs, technology platforms). To keep pace with the current, and often mandatory developments, banks are forced to continuously invest in their payment infrastructure.

Instant Payments (IP) will become mandatory for large parts of Switzerland starting 08/2024. However, classic Acount-2-Account payments will remain a commodity product that primarily generates costs; the experience from the SEPA region, the UK or Russia shows that also IP in its pure form does not change this and can hardly be monetized for the broad market.

Accordingly, it can be observed how banks in many other jurisdictions choose “the path of the supposedly least resistance” and place a system for IP "adjacent" to the existing system landscape - often a crucial mistake. Even though this path enables banks to implement regulatory adjustments promptly, it simultaneously adds complexity in the system landscape. As a result, a supposedly cost-effective implementation leads to the parallel operation of two independent payments systems, which in turn implies double costs for “run” and exponentially increased expenses for future “changes”. Furthermore, with such a proprietary architecture, future use cases based or not based on IP - which create added value for the customer - cannot be implemented or can only be implemented in part or lead to a duplication of costs.

For this reason, even if the initial focus is placed mainly on achieving IP readiness, banks' transformation projects should be designed with the future of payments in mind, and that in such a way that the institutions' medium- and long-term competitiveness can be ensured or even enhanced. IP offers an excellent starting position for this because the introduction of it requires adjustments throughout most of the payment processing chain, including operating processes. When considering the solution space, adaptability, modular expandability, and maintainability in a modern architecture should be consistently evaluated against the background of a) the current requirements from IP and b) capabilities that will become necessary in the future. Those who understand these comprehensive adjustments as an opportunity and actively use the design space to streamline their structures as well as remove technical debt will achieve a significant competitive advantage, subsequently reducing costs and positioning innovative products based on Instant Payments on the market.

The accelerating evolution of the payments landscape is evident. Its significantly increased relevance is for instance reflected in the reporting on mobile payment methods in mainstream media such as the FAZ, NZZ or SRF. Mobile payment methods such as Apple Pay or TWINT are by no means the only innovations in the payments area, but rather only the tip of the iceberg. Payments are undergoing a multifaceted and, above all, fundamental change that will accelerate even more in the coming years. This change is essentially driven by three factors:

• steadily rising customer expectations in the retail and corporate sectors,
• new regulatory requirements, as well as
• significantly increased competitive pressure (e.g., from neo banks, FinTech companies or technology platforms).

While these factors have an influence on payments in general, we would like to distinguish at an abstract level between retail payment methods and payment transactions between two bank accounts. In the case of cashless payment methods, in which the funds are immediately available to the recipient, these can again be differentiated into two basic systems:

1. Customer-oriented payment methods with real-time clearing but deferred interbank settlement, such as TWINT P2P or PayPal
2. Real-time account-to-account payments with immediate settlement between banks, e.g., SEPA Instant Credit Transfer or IXB

The second method is often referred to as "real instant payment". In this blogpost, we will focus exclusively on the second system ii) real-time account-to-account with immediate settlement.

In consumer-to-business (C2B), peer-to-peer (P2P) and business-to-business (B2B) payments, banks and their customers worldwide are experiencing considerable demand for real-time transactions (Instant Payments, hereafter abbreviated to IP). These are accessible to customers 24/7/365 and ensure immediate availability of funds (usually
< 10 sec but varies by scheme) to the end customer for further use. So far, more than 50 countries worldwide have reacted to the developments in the payments market and introduced Real-Time Retail Payments Systems (RT-RPS), in which such a final settlement takes place in addition to the immediate clearing. In the USA, for example, it is expected that 20% of all credit transfers will be made using IP by 2024. And that in a country, that lags far behind the developments in the UK, the entire SEPA region or India with regards to IP.

Europe is making progress

The SEPA Instant Credit Transfer Scheme (SCT-Inst) was launched in November 2017 to ensure the harmonisation of payment transactions across countries and to avoid a fragmented European payments landscape. Even without regulatory requirements for the introduction of SCT-Inst, transaction volumes already accounted for approximately 8.6% of the total credit transfer volume in Europe in the first quarter of this year and is continuously increasing, as shown in Figure 1. 

Currently, IP-enabled service providers with the corresponding accounts and services are active in 23 European countries. However, each country differs significantly in the number of available services. In Germany, for example, there are approximately 1,250 IP-enabled banks and payment service providers (PSPs), while in France the number goes down to only 124.

The European Central Bank has set the goal of including all payment providers in such a real-time payment system by the end of 2021. Furthermore, as part of the Retail Payments Strategy issued in September 2020, the EU Commission has added some emphasis to this goal: if satisfactory numbers for the adherence to SCT-Inst are not achieved, the EU Commission reserves the right to make the support for IP mandatory. This becomes interesting combined with the statement, that “charges of both regular and instant credit transfers should be the same”, also made in the context of the Retail Payment Strategy.

Instant Payments to become mandatory in the Swiss financial market

Historically, Swiss retail and corporate banks have faced limited international competition. Largely undisturbed by external influences, they have been able to develop and operate a stable network of branches, products, and processing platforms. At the same time, they are also affected by the accelerated change in payments landscape, increasing the pressure for further development. Participation in these developments is crucial to ensuring the ability of Swiss banks to connect to the international market as well as their future viability, which requires corresponding investments in the payment infrastructure.

The introduction of IP in Switzerland thus follows international developments in payments. The central SIC clearing system, which currently processes RTGS (Real-Time Gross Settlement) payments in Switzerland, will therefore be extended to include IP. The payments regulator in Switzerland, the Swiss National Bank, is creating a far-reaching obligation for financial institutions to participate in IP. This stipulates that the capability to receive IP will become mandatory for approximately 50 of the largest Swiss banks from August 2024 and for all other banks at the end of 2026. Specifically, all banks with more than 500,000 incoming RTGS transactions in 2020 should therefore start preparing for the IP introduction today.

It should be noted that the individual readiness of each institution to implement a solution can result in differences in the quality of the solutions.  For example, the sole delivery of the mandatory reachability on the recipient side could be achievable through a (relatively) less expensive implementation, by focusing only on the most necessary system adjustments. However, this type of implementation could leave out aspects relevant for customer perception, thus neglecting the opportunity for market differentiation:  IP is therefore not equal to IP.

Payments are a commodity product

Account-to-account payments are a commodity product that essentially generate costs for banks, without banks being able to gain a differentiating feature on the market as a result. Like other infrastructure services, it is the foundation for all kinds of banking services and a relevant hygiene factor as such. Very few customers want to pay for payments services, but also very few customers would accept a reduction in the quality of payments processing.

The introduction of Instant Payments will not change this. The experience from the SEPA region after the introduction of SCT-Inst confirms this statement, where end customers are hardly willing to pay more (or any) for real-time payments. The same behaviour of retail customers can also be observed in the UK or Russia, when using IP in its pure form. If additional direct costs are introduced for IP, customers often switch to other payment schemes where only the payment advice is immediately visible, and the actual credit of funds to the bank account is deferred. Nevertheless, IP - in combination with more far-reaching services - is increasingly being positioned as a competing product to these alternative offers (but also to established solutions such as MasterCard or Visa), enforced by vehement political pressure. A prominent example here is EPI, the European Payments Initiative.

Complex changes of the IT landscape and processes necessary for the implementation of IP - but not only for IP

An example of a fundamental change to the entire payments processing chain is the migration to ISO20022. Here it became apparent that such an adaptation of the message formats cannot always be solved by a simple mapping when generating (or receiving) interbank messages. Due to the greater business scope covered with the new formats, this changeover mostly resulted in decentralised adjustments to the entire processing chain. In a similar way, the implementation of instant payment also involves a considerable effort for banks. To be able to offer customers the benefits of IP, financial institutions have to make extensive and complex changes to infrastructure, applications, and core banking systems, as well as internal processes. On the one hand, new functional requirements for IP must be implemented, e.g., the connection to SIC5 with the associated communication protocol (including the security framework, message types and changes to the risk and compliance screening processes). On the other hand, banks’ payments-related systems must meet more stringent non-functional requirements, as transactions must be processed within a very short time and with 24/7/365 availability. These fundamental requirements will lead to changes affecting most systems in a financial institution's IT landscape, as well as operational processes in multiple business units. Figure 3 shows functionalities along the payments processing chain that will need to be adapted when IP is introduced. 

Most of the functionalities that need to be adapted for IP are relevant for the processing of both outgoing and incoming payments. For example, it is necessary for both cases to support the protocol from SIC-IP service and to perform the required real-time postings and risk and compliance checks.

The services that are only relevant for outgoing payments essentially comprise the capture and management of outgoing payment orders (e.g., via e-Banking) and the authorization of the outgoing payment. Compared to the overall changes required for receiving IP, the scope of additional functionalities for sending IP is often much less comprehensive. From this perspective alone, it makes sense for a bank to enable the sending of IP in addition to the receiving and thus also to actively make the IP offering available to their own customers.

In addition to the efforts these changes already entail, some institutions may face additional challenges resulting from the complexity of a historically grown and often not consistently or strategically maintained IT landscape. Some indicators of an unfavourable starting situation for the implementation of IP may be:

• Highly individualized IT solutions,
• Strong or insufficiently transparent dependencies between system components,
• System components with outdated versions that cannot be easily updated to newer versions due to the above-mentioned points as well as release cycles that are not coordinated with each other,
• Vendor lock-in with existing partners and suppliers,
• Rising overall costs for operation and lack of budget for necessary change, especially in recent years.

Depending on the specific IT landscape, implementing changes to achieve IP capability may require additional effort to resolve pre-existing issues or components that are not directly relevant to IP, but are affected by the (sub-optimal) relationship between involved parties.

Need for action is evident

Considering the presented adjustments (which make a smooth implementation of IP capability a complex undertaking), it quickly becomes apparent that a project of this scale has a significant throughput. To be IP-ready on time by 2024 and avoid potential penalties and ad-hoc re-prioritization, a prompt analysis is necessary. Due to the number and complexity of technical, organizational, and procedural changes, an overview of interventions aimed at IP readiness is needed immediately. Based on SIC5 availability and an IP go-live in 2024, important decisions have to be taken now, so that a start of such a transformation project can be scheduled on time.

The tempting path of "least resistance" and its consequences

As a result of the above, there is already a trend in other countries to support the requirements of payments processing via a central payments hub. This is pursued in order to efficiently implement the increased requirements from IP and to centralize the processes across schemes. One example is P27 Nordic Payments, where pan-European clearing houses centralize their offerings and orchestrate common services. In Switzerland, such an offering, agnostic of core banking providers, is not being implemented. Solutions offered by the core banking providers are often closely intertwined with their own core banking system, thus creating further dependencies on their products, and limiting the banks’ strategic room for manoeuvre.

In many other countries with a similar setup, we can observe banks choosing the path of least resistance and placing a "single purpose" systemfor IP "adjacent" to the existing system landscape. An additional, parallel orchestration of the IP flows thus co-exists with solutions for non-Instant Payments. An obvious advantage of this approach are quick results which supposedly allow the fast achievement of IP-readiness. We can see this approach being promoted strongly by some vendors in the market. At the same time, a "single purpose" implementation also leads to the parallel operation of two independent payment systems, which implies double costs for run. Above all, this “single purpose” implementation potentiates the effort for future changes, which, as explained in Chapter 1, will increase significantly over the next years, subsequently increasing process complexity enormously. Among other consequences, the additional complexity will require future payment-related regulatory requirements to be implemented multiple times, in different systems. Furthermore, future IP-based use cases that would create added value for bank customers could either be partially or completely hindered by such a proprietary architecture. Therefore, such a “single purpose” implementation can be regarded as "sweet poison".

The solution approach to payment processing evolves differently in the broader market. In the past, new requirements used to entail redundant efforts, as all participants have had to simultaneously implement regulatory requirements or adjustments to message formats in their respective systems. These market wide inefficiencies were a major contributing factor to the consolidation of payments providers, resulting in the emergence of pan-European providers for such services. The foundation of their success is evident: they have managed to consolidate commonly used processing routes, thus achieving scale effects. Albeit on a smaller scale, the strategy for internal banking systems, should not go against this larger trend.

As described in the previous chapter, the introduction of IP requires far-reaching adjustments to the IT systems along the entire payment processing chain. This affects not only the core banking system, but also other systems such as risk and compliance systems, connectivity, or payment submission channels. Even if the initial focus is placed only on the introduction of IP, the transformation should be designed in such a way that the medium- and long-term competitiveness of the institutions is ensured. Therefore, the entire payment landscape should be considered, and no redundant process routes should be created. Ideally, any adjustments required to achieve IP-readiness should not lead to an increase in complexity, but to an improvement of the overall situation while anticipating future developments instead. Accordingly, adaptability, modular expandability, and maintainability in a modern architecture should be considered within the solution space against a) the current requirements from IP, and b) capabilities that will become necessary in the future.

For banks, there are basically three possible solutions through which the implementation of an IP-capable infrastructure can be achieved:

• Option 1: Build an IP-capable infrastructure for the sole purpose of IP deployment ("single purpose").
• Option 2: Build an extendable and future-proof infrastructure that, in addition to supporting IP, also handles the existing payment channels on a single infrastructure
• Option 3: Outsourcing of payment transaction processes to an external service provider

Option 1 -"Single purpose" implementation of an IP-enabled infrastructure 

By choosing this option, banks implement a "minimal" solution that supports only the short-term regulatory and technical requirements to deploy IP. This is a dedicated infrastructure which promises a low-investment IP-capable infrastructure, generally resulting in the setup of a separate payment route. With this option, the delivery of the necessary capabilities can be done in-house by the bank or through offerings in the market, such as those which can be purchased from a core banking vendor. In the case of an in-house implementation, a bank would deploy this solution “on top” of the existing system landscape, which implies the build-up of technical debt in the long term. Alternatively, the necessary components can be obtained from the market in the form of an IP module. In this case as well, the component is installed "adjacently" and runs parallel to the existing infrastructure. Both cases result in a two-fold expenditure for maintenance and operations. In the latter case, parallel operation of the two infrastructures also increases the already noticeable dependency on the core banking system provider. This supposedly cost-effective option often turns out to be a fallacy, especially when adjustments that will be necessary in the future are considered.

Due to its proprietary nature and close linking of the processes to the core banking system, another drawback of this option is its low (or lack of) adaptability. This makes the resulting solution unfit for other payment types or use cases based on IP. 

Option 2 - Building an adaptable and future-proof IP infrastructure

With this option, banks decide to set up an IP-capable infrastructure individually. In addition to meeting short-term regulatory objectives, the infrastructure needs to also be adaptable and future-proof. This requires that financial institutions not only implement the corresponding processes along the payments processing chain in accordance with the SIC rules and regulations, but also align the entire payments infrastructure in advance and consistent with future requirements.

Specifically, the development of the solution should ensure that an IP-capable extension of the infrastructure is implemented with minimal intervention in the existing system landscape and without creating additional technical debt. This can be realized by building a process control which relies on existing interfaces rather than on IP specific proprietary integration. If this is not directly possible, new interfaces must be standardized so that they can accommodate all payment types. Otherwise, additional effort would incur for the integration of further payment channels, as well as additional expenses would arise for redundant maintenance in the event of future adjustments. The payment processing systems should therefore be flexible and extendable through modules, so that future use cases can be integrated via standardized interfaces and do not lead to duplicate processing paths.

In this respect, evaluating an adequate solution should consider quality goals for IP, but also adaptability to future products as well as the integration of further payment submission channels (such as schemes) and maintainability.

The responsibility for a prompt and complete IP capability, including connectivity to SIC5, lies entirely with the respective bank, which must also carry the full investment costs. Additionally, this option requires the bank to maintain or build up the necessary expertise and competencies in-house.

Option 3 - Outsourcing of payments to an external service provider 

The last option follows an outsourcing approach. Here, the banks decide to outsource payment processing to a service provider who takes control over the complete process and only calls dedicated functions via standardized interfaces on the bank side. The service provider takes over the implementation of connectivity to the SIC5 Clearing & Settlement Mechanism (CSM) and confirms compliance with the corresponding process requirements. Time-critical services such as Risk Scoring and Compliance Screening Services (RCS) or bank-specific checks can also be outsourced, allowing banks to focus largely on reserving and booking payments. However, the exact intersection of the services to be outsourced and those to be provided by the banks themselves must be made consciously and requires a well-founded analysis. Otherwise, the disadvantages from option 1 may come into play. Under the right system delimitation, adaptions required at the bank’s systems are limited to the implementation of interfaces for calling individual services provided by the bank and real-time bookings in the core banking system, as well as ensuring the availability of the corresponding components.

This centralized approach shifts some of the responsibility for implementation and all the responsibility for cost risk to a central entity. For smaller banks that do not have the corresponding expertise or budget for their own integration, this may be a viable option. For larger banks, which have not defined payments as part of their market differentiating product portfolio, this option may also be attractive. However, such an initiative requires the willingness to reach consensus among the participants involved.

Various aspects play a role in the evaluation of the proposed solutions. During project initiation, responsibilities for analysis, initial implementation, further developments, and operation of the respective components must be defined. Ensuring the appropriate expertise in such an implementation project should not be underestimated, especially by smaller banks. Attention should also be paid to the speed of implementation, as the maturity of the status quo and dependence on peripheral systems can lead to demanding fundamental architectural changes at the bank. Finally, the costs (investment costs, as well as operating and maintenance costs) should also be considered at this point.

When comparing the options, the following can be summarized:

Option 1 "Single Purpose"Implementation - not recommended regardless of the possible variants. Banks should overcome the need to take the path of least resistance, even under time pressure, and carefully evaluate other available options instead.

Option 2 Implementation of a future-proof IP infrastructure - is recommended for banks with a highly customised or even in-house developed core banking system, which therefore have a strong and powerful IT department. These institutions may be most comfortable with an individual independent implementation, so that external dependencies can be reduced to a minimum. However, it must be ensured that market standards, that are formed de-facto, are not disregarded. Standards defined by, for example, manufacturers of core banking systems, banks, or other market participants (also internationally!)  must be identified in advance and should be considered accordingly.

Option 3 Outsourcing - can be reasonable for smaller banks that do not have the expertise or budget to conduct an individual integration, but also for larger banks that benefit from the expected standardization of processes and interfaces. However, such an initiative no longer exists as a joint undertaking on the Swiss banking market. Should this nevertheless be considered as a valid option (for example, for banks which do not consider pure payment as part of their differentiation strategy), existing partnerships should be identified and evaluated and, if necessary, a new project coordinated.

Instant Payments are about to become a reality in Switzerland, and as such, will be quickly accepted and expected by customers as the new normal. A comprehensive strategic positioning of the product, a supposedly simple implementation ("single-purpose implementation" or "receiving only") or even a way around it therefore does not exist and is not necessary. In fact, IP-readiness will require comprehensive adaptations and adjustments in existing processes as well as IT landscapes of banks, thereby limiting the implementation effort from “a lot” to “a whole lot”. The need for Swiss banks to act and decide on an implementation strategy for Instant Payments is imminent. A delayed introduction might lead to uncomfortable situations where re-prioritizations become necessary, producing additional costs and problems. It is therefore well advised to leverage these comprehensive adaptations as an opportunity to gain a strategic edge and to actively use the opportunity to correct structures and technical debts, subsequently reduce costs and position innovative products on the market based on IP as the new standard.

Figure 1: Share and development of SCT-Inst in the total European credit transfer volume - European Payments Council

Figure 2: Instant payment penetration in Europe - European Payments Council

Figure 3: Business areas and services affected by an IP conversion - CORE based on BIAN capability map