Industry
TCS BaNCS™
TCS BaNCS™: Enabling Transformation in Banks and Financial Institutions
Highlights
- TCS BaNCS for Payments supports the recommended SWIFT CBPR+ conversion rules for all different address types, to prevent loss or truncation of data.
- ISO 20022 standards have set up the base for frictionless payment processing across the country, adding up to more than CHF 3 BN per year, making Switzerland a leading player in adopting ISO 20022-based payments.
- Payment standards are evolving to be ISO 20022-based, and TCS BaNCS for Payments’ internal processing models are already built on this standard.
On this page
Swiss payment processing
The evolution of payment processing in Switzerland is a good showcase for how payment journeys can be supported in a frictionless way with TCS BaNCS for Payments.
Some history and background
The Swiss domestic payments ecosystem is dominated by two large players, SIX and PostFinance, and they each process payments differently. The last seven years have witnessed many evolutions in the domestic payment ecosystem in Switzerland – migrating legacy formats in payment initiation and interbank processing, ISO 20022, unifying domestic payment clearing in SIC RTGS (Real-Time Gross Settlement), interoperability with SEPA CT (Credit Transfer), and SEPA DT (Debit Transfer).
On top of these evolutions, legacy payment slips have been decommissioned and replaced by the new QR-Code slip, the so-called QR-Bill, providing depth of payment based on ISO 20022 elements.
ISO 20022 standards have set up the base for frictionless payment processing across the country, which adds up to more than CHF 3 BN per year, making Switzerland a leading player in adopting ISO 20022-based payments.
Various Swiss payment methods and credit transfer breakups.
1) ISO format changes in the Swiss market
Challenge
SIX opted to support one version of the ISO 20022 message format in interbank message exchanges to help streamline domestic interbank processing.
The challenge for banks is to support previous and actual versions of ISO 20022 towards their customers for payment initiation (pain.xxx) as well account statements (camt.xxx) for both production as well as customer test environments. The response (pain.002) to customer credit or debit order initiation (pain.001/pain.008) needs to have the same version and related mapping. Also, large corporate customers with different applications for payment initiation or consumption of account statements need a period of coexistence of both formats to migrate all their systems to the new ISO version.
Resolution by TCS BaNCS
TCS BaNCS for Payments supports mappings to the corresponding standard release formats of supported schemes, e.g., SIC, SEPA, and CBPR+. The interface layer maps the ISO message content to the product’s internal processing model, decoupling the message content from the processing layer while supporting multiple ISO versions.
Previous formats of business functions are still available, and new capabilities target ISO versions implemented per market standards or according to a bank’s need.
For customer account statements, both previous and current versions of statements are created, and this co-existence will be supported until the migration to the new ISO version is completed. The supported and delivered account statement versions can be managed in the delivery instructions from the customer.
2) Swiss e-Bills
e-Bill is a SIX initiative that digitizes paper invoices. Billers can select from 18 providers to acquire their eBills, with eBill processing centralized in Paynet/eBill.ch. 2.7 MN payers presently use e-Bills, with 95% of banks in Switzerland supporting 400 MN of e-Bills efficiently processed in a year, with no reported fraud.
SIX and the Swiss banks are in discussions regarding a pilot in 2024 to transform Swiss domestic Direct Debit to eBills with mandate management and recall requests by payers as a further evolution to streamline domestic processing.
eBill integration
Challenge
The existing eBill payers, once migrated to the new platform, receive new eBill participant identification. The next step is for the participating bank to map this eBill participant identification to the eBanking user ID of the payer. In the eBanking session, the customer can directly inquire about, approve, or reject the eBill. Within five seconds, the approved eBill is visible as a pending payment order.
Paynet/eBill.ch acts as the initiating party and creates a payment order (pain.001) with dedicated mapping to the payer bank. The bank needs to validate the payment and eBill participant identification to the debtor account.
Resolution by TCS BaNCS
The existing order management for pain. 001-based orders required the following enhancements, provided by TCS BaNCS:
- eBill payment order (pain.001) mapping used by the payment initiating party Paynet/eBill.ch
- Additional validation of payer eBill participation, which requires integration of additional master data on debtor account.
- Streamlined and enhanced existing payment orders for express processing to provide a turnaround time of five seconds for acquisition/ validation and additional notification on execution.
- Performance scaling to scope with the high volume of eBills.
3) Payment slip evolution to QR-Bill
As of September 2022, PostFinance, as owner of Swiss payment slips, in cooperation with SIX, mandated the switch from legacy payment slips to QR-Bills and their integration into e-Bills. The mandate was a bid to improve STP processing and improve references and acquisition usability with easy and error-free scanning that addresses the need for compliance, like details of payer, beneficiary, ultimate debtor/creditor, structured address, and ISO 20022-based mapping.
The new QR-Bill is now the only domestic payment slip with structured and unstructured remittance information (EU compatible SCOR and domestic QRR) used in Switzerland. It simplifies payment acquisition and processing while also reducing errors.
QR-Bill (payment slips)
Challenge
The legacy payment slips (IS = payment with no structured remittance for beneficiary with bank or postal accounts/ISR = payment with structured remittance) and related domestic message formats and processes were decommissioned with QR-Bill, the QR code-based slip.
QR-Bill content is ISO 20022-based, supporting remittance with structured and unstructured references. To scope with the existing structured reference to domestic ISR (red and orange payment slips), the same semantic was taken forward as QRR (QR reference) in the new QR-Bill. For interoperability reasons with SEPA payments, the SCOR reference was supported as well. The slips can be used with a pre-printed transfer amount or free transfer amount. The slips support unstructured and structured addresses based on the ISO 20022 postal address to enable frictionless (and truncated) processing in domestic and cross-border payments.
Additional information, as free text or structured text, bilaterally agreed or based on the SWICO specification, can be exchanged to streamline follow-up processing of the payment between biller and payer.
Resolution by TCS BaNCS
In our study of the QR-Bill specification and related use cases, we discovered that QR-Bill is not just mapping a new payment slip. TCS made the following recommendations to our bank customers when implementing the QR-Bill:
To prevent fraud, the customer bank must verify that the address held in the QR-code must be the same as in the plain text printed on the payment slip on acquisition.
- If provided, the optional ultimate debtor needs to be manually captured during scanning or acquisition.
- The beneficiary IBAN has a different clearing number identification when structured reference QRR is used. IBAN for QRR is called QR-IBAN, through which clearing number identification is checked in the SIC participant directory, providing additional opportunity for clearing IDs for a bank using QR-IBAN.
- Bulk credit for corporates needs to be enhanced to support QR-Bill-based payments.
SIC 5 platform and SIC IP (Instant Payment)
The SIC 5 platform uses ISO 20022-based message standards for domestic CHF and EUR customers and FI2FI payments processing and clearing, enabling higher availability and instant payments.
SIC IP will be the first service implemented on the SIC 5 platform. SIC IP will be rolled out as a pilot in November 2023, and it will become mandatory for all SIC RTGS participants by the end of 2026.
The remaining SIC 4 services for RTGS in CHF/EUR will migrate in the next few years to the SIC 5 platform.
Interoperability SIC – SEPA
Challenge
The bank must provide interoperability in domestic and SEPA payment processing.
In the 2022 standard release, SIC 4 RTGS moved to ISO 20022 v2019 for SEPA CT, leaving DT with the nonstructured addresses of ISO 20022 v2009.
In the standard release in 2023, SEPA will be moving to the ISO 20022 v2019 format for both SEPA CT and DT.
Swiss customers may send payment orders (pain.001) in format v2009 or v2019, and co-existence with ISO v2009 for Swiss customers is allowed until November 2026.
Resolution by TCS BaNCS
TCS BaNCS for Payments uses ISO 20022 v2019, allowing both inbound and outward mapping for SEPA using either v2009 or v2019 formats. This allows structured addresses of internal models to be mapped to unstructured addresses for outward SEPA processing.
SIC 4 RTGS and SEPA messages use their own scheme-driven mappings, which are decoupled in the TCS BaNCS integration layer towards payment processing.
Processing follows the ISO 20022 baseline, which can be orchestrated to the banks’ needs, following scheme-specific flavors.
Interoperability SIC - SWIFT
Challenge
SWIFT has set about its technical readiness journey with the first step of MT to MX migration, with the MT to MX co-existence phase planned to continue until November 2025.
The depth of information and referencing of transactions is considerably improved with MX formats. Structured addresses in MX have improved the depth of data in comparison to legacy ‘structured’ addresses in MT format, which provides only the segregation of name, street, and compound address line with postal code, town, and country.
During the co-existence phase, the bank can migrate stepwise from MT to MX, depending on their partner database in their core banking system. However, the depth of data from MT can impact the depth of information related to recall requests, returns, cover payments in MX requests.
Banks using MT during the coexistence phase often have truncation issues (MT fields 70, 72 of customer and FI2FI payments). This topic was addressed by SWIFT PMPG, where a proposal was made for MT messages (MTx99) to forward or claim truncation and missing data. PMPG expects that less than 1% of SWIFT messages will be impacted by such truncation.
In the interoperability of SIC – SWIFT corridor payments, the data truncation could block the STP processing of intermediaries.
Resolution by TCS BaNCS
TCS BaNCS for Payments uses ISO 20022 for its internal operational model and MT-based payments. With the ISO 20022 database and enrichment of truncated MT fields out of MX, the information is sufficient for a smooth start with MX-based exchange in the SWIFT network.
The data truncation of MT can be mitigated in two ways, which need to be aligned with banks’ requirements and their related cross-border businesses:
- Automatic enrichment of truncated MT fields out of MX message in SWIFT FINPlus in case of truncation in fields:
- MT field 70: ultimate debtor/creditor, unstructured remittance information, previous instructing agent
- MT field 72: previous instructing agent, instruction for creditor agent
- STP break of MT payments with truncated data. Enrichment of truncated MT fields out of MX message with MTx99 ‘data truncation’ request to the previous instructing agent to get the full content of truncated data. The missing truncated data will be captured in the pending payment for further processing.
TCS BaNCS for Payments supports the recommended SWIFT CBPR+ conversion rules for all different address types to prevent data loss or truncation. With TCS BaNCS for Payments, the ISO 20022-based operational model is a good anchor to support:
- Inward SWIFT MT or MX, mapped to ISO 20022 operational model, further processed in SIC as interbank (pacs.00x, camt.0xx) message
- Inward SIC (pacs.00x, camt.0xx) message, mapped to ISO 20022 operational model, further processing in SWIFT as MT or MX message
- Outward SIC or SWIFT ISO 20022 messages based on the TCS BaNCS operational model
Swiss QR bill requirements, challenges and TCS BaNCS resolutions
TCS BaNCS approach towards market-related changes
TCS BaNCS’ product management follows a methodical approach to adopt and drive market innovation and regulatory changes. We are enhancing our product to cover market changes with added values like high STP with limited manual intervention, additional functionality required by the bank, and support smooth integration in its ecosystem leveraging existing APIs.
- Identify market changes
Regularly screen market innovation and regulatory changes. Publicly available or non-disclosed information of partner banks or standardization organizations like SWIFT are used for such analyses.
- Validate understanding of market changes
In dedicated banking working groups or with partner banks, TCS is validating their understanding of market changes and the associated impact on existing products offerings, STP processing (what needs to be adopted within TCS BaNCS), and related ecosystems (what needs to be adopted outside of TCS BaNCS).
TCS BaNCS’ methodical approach to adopting and driving market innovation and regulatory changes.
- Have a disruptive view of market changes
Based on a deepened and verified understanding, a disruptive way of integration of market innovation, new offerings, and ways of processing, e.g., linking with ML/AI, lean processing, is explored and discussed within TCS BaNCS’ Working Groups or with partner banks.
For example, real-time processing and Request-to-Pay schemes are driving new ways of event processing. ML/AI and digitalization are expected to gain more traction to streamline STP processing.
- Adopt to market needs
With the defined product scope revisited with a disruptive view and impact of integration, the design is defined with respect to the reusability of existing capabilities, open gaps, and the parameterization of the product and services.
- Support integration of market adoption
TCS leverages its experience of other market implementations and lessons learned with partner banks to support the integration and roll out of market-specific changes at customer banks.
In previous chapters, we explained how the TCS BaNCS approach was applied.
TCS BaNCS for frictionless payment journeys
Payment standards are evolving to be ISO 20022-based, and TCS BaNCS for Payments’ internal processing models are already built on this standard.
The product’s software architecture and depth of functionalities, be it for credit or debit transfers, checks with adoptation to a specific region/country (e.g., SEPA, SIC), is helping banks with the seamless processing of payments.
TCS BaNCS’ service integration as an interface layer manages message exchanges used to process payments. It shields the different ISO versions and scheme-related flavors towards payment processing. Different versions of ISO 20022 messages only impact payment processing, where business logic needs to be adopted.
The existing integration in the bank’s ecosystem could be further used or partially enhanced where additional information on the new version of the message is required.
The evolution of payment processing in Switzerland is a good showcase for how payment journeys can be supported in a frictionless way with TCS BaNCS for Payments.
Payment standards are evolving to be ISO 20022-based, and TCS BaNCS for Payments’ internal processing models are already built on this standard.
The product’s software architecture and depth of functionalities, be it for credit or debit transfer, checks with adaptation to a specific region/country (e.g., SEPA, SIC), are helping banks with the seamless processing of payments.
