The history of cross-border payments began with… cooperation with the media. From the 1970s until the beginning of digital banking, banks used long-distance telegraphs from the Reuters news agency for cross-border transfers. This solution has been adopted by the Society for Worldwide Interbank Financial Telecommunication (SWIFT) to settle payment orders on correspondent accounts of individual institutions.

In the times of fledgling digitalization, data used to identify the transfer was sent by telex, in the then accepted text format MT, which was organized like a telex form. One field represented one piece of information and was expressed with a number instead of a word. For example, 13C is a time stamp and 26T is a transaction type. One transfer required a total of several dozen “fields to be filled”, i.e., transfer information to be provided. As a result, the received message could be deciphered into all languages.

Goodbye SWIFT MT, welcome SWIFT MX

The main MT message format used for interbank clearing by SWIFT has not changed since the 1970s, however, the tools used to process it did as the message was expanded over time. One of such improvements was the introduction of an additional SWIFT code to identify the financial institution in the international banking pool. That’s how the bank’s ‘address’ was born, the BIC (Bank Identifier Code), which is the ID of the financial institution in the SWIFT system.

Over time, several fully digital standards for transferring transactions have emerged besides SWIFT: TARGET2, SEPA Credit Transfer, or TIPS. However, all of them have a smaller range than those based on the MT SWIFT message. Although banks today have the technical capacity to send large volumes of transactions instantaneously, one of the bottlenecks that prevents this is the legacy MT message type.

No wonder the banking world has decided to introduce a new and more universal language for international transactions. From November 2022, a new format for cross-border transfers enters into force, MX. It is the successor of the MT format, but adapted to the capabilities and expectations of Data-Driven Banking. Based on the XML structure, the MX messaging type enables easy data exchange in a common, flexible standard.

MT/MX conversion: the quest for context

By creating a common “language” and model for payment data, ISO 20022 significantly improves the transparency and efficiency of transactions. In addition, richer and structured data will open up new possibilities for personalization and improvement of the bank’s customer experience. However, the introduction of a new communication standard is fraught with considerable difficulties.

First of all, there is no common dictionary” that would allow direct translation between different message formats. While the conversion from “new” to “old” format (MX to MT) is relatively simpler, from “old” to “new” (MT to MX) it requires advanced knowledge of the relationships between individual message elements.

The “new” message (MX) has a multi-level, organized structure, which allows easily and unambiguously to aggregate its elements and assign them correctly to the “old” MT format. On the other hand, the data clusters in the “old” MT format do not always have clear rules for interpreting (“unpacking”). Meanwhile, the system that converts the message must “know” how to break down each incoming information into single components, and then properly recreate it in the default format so as not to lose any information and certainly not to generate an error.

Example:

Bank (BIC: EXABNL2U) from Utrecht, The Netherlands, received a transfer order from his client ACME NV (Amstel 344, Amsterdam) to transfer 12,500USD on October 29, 2019 from the account no. 8754219990.

In the “new” MX message (see below left), each value is contained in a separate element that has a unique label to identify and interpret its value. In the “old” MT format (right), the same values are much more difficult to interpret.

These translational difficulties are best seen in two elements:

1. Amount, currency, and date of the transaction:

The illegibility of the MT message is obvious. Two-way translation can only be done with clear conversion rules.

2. The address of the ordering party:

In the MT message, all customer data – the ordering party is under a single label (50F:) with the account number, whereas the address is divided into consecutive lines (1/, 2/, 3/) with no differentiation into the name of the city, street or country.

If the address is typical and the elements are not too long, the address will read as shown in the illustration (1/company name, 2/street and number, 3/country/city). However, if the company name is longer than 33 characters, then line 2/will not contain the street and number, but will continue the name of the company. On the other hand, if the address also includes the name of the state/province, address line 3 will not hold all the information, and perhaps an extra line 4 will be added.

As you can see, assembling the address in line 50F: is simple in the case of the MX message, but the reverse conversion requires knowledge of the context. For example, knowing that there are four lines and a European country (BIC address!), we can expect a “classic” address and a long customer name (lines 1 and 2). However, if the address is US-based, the last line must be interpreted as a country/state/city.

These examples show that the translation of MT/MX messages can be really complicated in some cases. It is like looking for an address in a foreign city. As long as the street names and numbering are standard, you will easily reach your destination. However, with a non-standard address, it is easy to get lost. Without a thorough understanding of the anatomy and context of the message, i.e., different naming and numbering methods, the banking system can also get lost in MT/MX translation.

When preparing to launch an ISO 20022 SWIFT MT to MX converter, it will be difficult for a  developer to know how to relate the old and the new message formats for a glitch-free exchange. In-depth knowledge of the banking process and its intricacies is the area of expertise of the banking system analyst. Their domain knowledge allows scrupulously analyzing the scope of tasks ahead and preparing implementation guidelines for developers. My colleagues discuss the benefits of working with banking IT analysts in this article.

MT/MX converter: more than a temporary solution?

When the changes required in the new communication standard have been mapped, it is time to select the strategy for their implementation. The bank can add a ready-med ISO 20022-compliant interface to its core system, or develop its own solution. There is also a third approach: a SWIFT MT/MX format message converter. Some organizations choose it as a temporary solution because of limited time or budget. On the other hand, some choose a solution that solves the immediate problem, and at the same time is future-proof and meets the goals of their long-term development strategy. 

Translators supporting data validation, enhancement, and conversion between different standards or formats are already becoming available. One of them is the native SWIFT MT/MX converter. This solution will certainly be used by large international organizations. However, its complexity, as well as the costs of implementation and maintenance, do not make it a good fit for every organization. Organizations that need an optimized MT/MX converter can use the independent MT/MX broker that is a business application integrated with the core system. A good example of such a solution is our proprietary system, Payres.

MT/MX converter: light solution, great possibilities

As a SWIFT MT/MX message translator, Payres enables the settlement of SWIFT XML ISO 20022-compliant international payments. As a “lightweight” MT/MX message broker, Payres eliminates the need to modernize core systems and maintain the efficiency and flexibility of the banking architecture. The solution is cost-effective and does not require a complicated implementation process. Payres works in Real-Time Transform (RTT) flow, and the support of the Drools rules engine minimizes the inevitable delay resulting from the serial position of the translator in the payment message path.

Payres wsupports back office applications that do not support the new format, or do so only partially. Our message broker automates transaction processing between back office applications and external networks.

However, unlike “classic” MT/MX converters, Payres processes data in real-time, automatically leveraging the data flowing between the bank’s core system and the integrated applications. Payres is suitable even for organizations that plan to ultimately implement MX messaging in the core system itself! When it is no longer needed as a MT/MX converter, it can support real-time data activation in line with Data-Driven Banking.

Breakthrough changes go well with long-term perspective

The temporary converter is a perfect solution to maintain communication in the global banking world after the launch of the “new” communication standard in November 2022. However, banks that make do with a temporary MT/MX translator and neglect to thoroughly modernize their IT architecture will have to make extra effort to catch up, as explained by the experts interviewed by the Red Compass consulting company. With the “banking Esperanto” of ISO 20022 at your disposal, you not only gain a universal language in which to communicate, but also new business opportunities. To use them, choose a Data-Driven Banking-ready solution that will generate added value, both now and in the future. Need support in migrating to ISO 20022? We look forward to hearing from you! We are a team of professionals with experience in advanced payment processing projects, e.g. card payment messages for international clients. Learn more about our proprietary MT/MX converter here.

The post MT/MX converter: parlez vous ISO 20022? first appeared on CCA Europe.

Artykuł MT/MX converter: parlez vous ISO 20022? pochodzi z serwisu CCA Europe.

George E.P. Box, dubbed “one of the greatest statistical minds of the twentieth century,” said discovering the unexpected was more important than confirming the known.

This statement perfectly sums up the responsibility that software testers in banking take. Sometimes a minor bug that hinders payment processing can cost a business millions of dollars.

To avoid such a disaster, an experienced team of qualified testers is necessary. But how do you know if a tester is qualified? Or rather, how do you know if they are qualified to test a given application or process that involves several separate systems? It turns out that when it comes to testing specialized applications, especially when it comes to BFSI (Banking, Financial Services, and Insurance) applications, there is no going without industry-specific knowledge!

BFSI application testing: the golden triangle of skills

Danny R. Faught of Softwaretestinghelp.com lists three categories of software tester qualifications: testing skills, as well as domain and technical knowledge.

It goes without saying that every tester should have basic testing competencies and the necessary technical knowledge. However, in banking software, the concept of “proper application testing” is much more complex than in other industries. Errors of minor banking system functionalities can have huge consequences, not only financial, but also image-related and legal. This is why in banking domain, the reliability bar for IT solutions is set extremely high.

Contrary to “classic” consumer applications, banking applications require specific knowledge of banking processes: their course and interdependencies between system applications. Without this knowledge, the tester will not be able to prepare a specific case for automatic and manual tests that correctly reflect the course of the way of thinking and actions of the end user of the tested solution, based on the implementation of specific business processes. Consequently, it will not take care of checking the given test cases that determine the proper functioning of the application. Read more about specificity of banking domain testing.

Banking domain testing: who has the know-how, rules

Currently, domain experts are more often employed in performance testing and functional testing. And that is well enough. Why? In fact, banking domain testing requires not only an army of testers, but above all a team of analysts with in-depth domain knowledge.

Without knowledge of a given banking domain, the entire testing process will be weighed with enormous risk. It is mainly about the insufficient coverage of the testing scope, which, unfortunately, will be quickly and painfully verified in the production phase. In-depth knowledge of the banking process and its relationships is necessary to scrupulously analyze the scope of tasks and prepare test scenarios. Only with this approach to application testing will it be possible to detect all critical errors in IT systems, ensuring customer satisfaction with the bank’s services and security to money.

When a bank outsources software testing, it does not necessarily specify in advance what functionality to test and how. It often presents only documentation (functional or technical) that is not yet as standardized as e.g. technical documentation in the construction industry. It is the experienced analysts who have to design the entire process in such a way as to ensure maximum coverage with the least cost. Only then do the testers start working to finally present the results and recommendations. For more on  how to gain knowledge in BFSI testing, go to Softwaretestinghelp.

Functional test outsourcing: knowledge is added value

Testers with domain knowledge have a better understanding of specific business processes in a given industry, so they can more fully ensure the coverage of tested applications or processes. One of the industries where this is best seen is banking. However, what to do when testers with specific BFSI skills are simply not available in-house at the moment?

The outsourcing of functional tests to specialized partners is not yet popular in the banking domain. The main barrier is not the complex systems of a given bank, but the security requirements and legal regulations. The belief that the in-house team will prepare test cases better, and then run tests and report the entire process more accurately also plays a role. However, in the absence of adequate staff, hiring an experienced team of external testers is a more cost-effective and efficient solution than hiring and training new staff in BFSI tests. Today, new banking IT solutions simply cannot wait!

Specialized tests require specialized testing tools. At CCA Europe, we have a proprietary tool at our disposal: PATT, the world’s only native FIS Profile automated testing platform. Our proprietary solution also supports automatic tests of other IT systems and applications. To increase the level of automation, we have integrated PATT with Selenium.

Need support in the analytical or execution phase of your BFSI application testing project? Looking for a partner who is experienced in the banking domain to handle your functional tests? Feel welcome to a 30-minute call with our CEO, Jacek Nowak, no strings attached.

The post Banking application tests: in the golden triangle of domain knowledge first appeared on CCA Europe.

Artykuł Banking application tests: in the golden triangle of domain knowledge pochodzi z serwisu CCA Europe.

Clearing House Automated Payment System (CHAPS) is the fastest payment model in the UK and one of the first European instant payment systems. In the coming months, the system will face a revolution: switching to ISO 20022, the new global standard for payment messages.

The decision to join this global messaging standard was made back in June 2018 by the Bank of England, Pay.UK and Payment Systems Regulator. In late 2020, the formal preparations were completed, and financial institutions operating in the UK officially launched their ISO20022 implementation programs.

However, this is a complex project, executed under  pressure with limited time. The scope of the implementation  is huge and requires in-depth testing. However, in the future financial institutions that implement ISO 20022 in CHAPS will be able to obtain more detailed and better-structured reference information. Additionally, the new messaging standard will reduce manual interventions, which means potentially fewer delays for the customer. 

The ISO 20022 clock is ticking

To meet the implementation challenges on time, financial organisations will need to introduce massive changes in all bank architecture systems, processes, and technologies. The sheer scale of the work required for ISO 20022 takes an average of two years to implement. In addition, it is a very sensitive area of the bank’s operations. A single failed transaction worth several million pounds, for example, a major order from a business partner, or a real estate transaction, can have serious business consequences. Those banks that  start transforming their infrastructure last will have to face an enormous challenge, when the schedule is tight. However, this is only the first step. If banks are late in this respect, the delay will also affect the next steps.

A buffer that acts like a time shield

Since the Bank of England will enforce messages in the new format in June 2022, systems that haven’t been migrated will not be able to receive the new CHAPS messages. Is it possible to secure failure-free information exchange if the systems in your bank are not ready yet? In the event of a project delay, is it possible to provide access to both message formats?

Until all systems in your bank are tested and ready to receive messages in the new format, an independent temporal buffer, Payres, can help. Installing this system at the interface between incoming messages and banking applications allows “translating” incoming messages in real-time, both ways.

Payres transforms incoming messages from the new format to the old one, so that systems that are not ready by June 2022 can easily receive messages in the new format. Next, Payres transforms back the information generated by non-updated systems in the old format to the new one, and sends it back, ensuring continuity of data exchange.

Our solution can be adapted to the ISO readiness level of specific applications in the banking ecosystem. In this way, those institutions that do not manage to complete the implementation of ISO 20022-compliant solutions will not only be able to use the new format, but also leverage the new communication standard to their advantage as additional information becomes available. Payres can be a kind of “time stretcher” for banks to work on adapting their systems even if the work schedule goes beyond June 2022.

Payres supports and boosts your ISO 20022 migration

Buying time for the analytical and development phases is one thing, but what about the testing phase? With ISO 20022 implementation in CHAPS, the amount and quality of tests to be performed is greater than in any regulatory projects in the last 10 years, including SEPA. It would take a long time to create such test cases manually, but with Payres the process can be significantly accelerated and streamlined. During the translation from the old to the new format, Payres collects messages that can be reused in automatic ISO 20022 readiness tests of individual applications, after anonymization. 

Payres also supports the various stages of implementation of the new message format in individual business applications. Each format of the messages, new or old, can be redirected between systems using business rules in Payres. This is how you can decide which system receives which format.

In the next phase of ISO 20022 implementation, when messages will be enhanced with additional information, Payres will be able to use the new content to create added value. With properly designed business rules, Payres can capture additional information contained in messages and launch the desired actions in external systems. This way, the bank may activate additional processes, doing one more step on their data-driven concept implementation path, even before the competition!

Support your corporate clients and create added value

The implementation of the new CHAPS Direct standard applies not only to banks but also to their corporate clients. The largest manufacturers or service providers automatically process and book tens of thousands (or more) of large-format transactions per month. Of course, corporate accounting and billing solutions need to adapt to the new exchange format. 

As an experienced partner advisor, your bank can offer additional migration time to your corporate clients. If a number of them require additional support in translating messages into the new format between their ledger systems and your bank’s core system, this can also be handled with Payres. If single cases require support in this respect, your bank can create a consulting service with added value. Referencing them to companies that handle the mitigation of adverse consequences of implementation delays, that can minimize the impact of changes related to the implementation of ISO 20022.

Payres safeguards your transition to ISO 20022

As Payres accompanies the process of implementing the next stages of ISO, it can be used as a shield to support and leverage new data in real-time, while gaining time to complete the implementation and testing in the banking architecture. Payres shields you against the deadline, and at the same time allows you to use the new information immediately when and where the bank is ready for it, in the form in which it can be used. 

What’s more, Payres is a future-proof solution that secures not only the first but also the subsequent stages of ISO 20022 implementation, when the use of additional information comes into play. Just add new business rules that will activate new data exchange processes. Systems, messages, and even individual information in the message can be modeled with business rules. Payres can handle any business scenario. It also works well in medium and smaller banks, because it does not require complicated, long-term, and costly implementation.

The implementation of ISO20020 is a complex project, executed under time pressure. If you need qualified human resources or would like to take advantage of our consulting support, please do not hesitate to contact me.

Author:
Jacek Nowak, CEO at CCA Europe

For over 16 years, CCA Europe has been providing specialized software for the financial sector in Poland and globally. As a team of over 30 experienced specialists, they have carried out comprehensive core banking system development projects, payments, card transactions, internet, and mobile applications, as well as automation and tests.  The company specializes in card and payment systems. The company has successfully collaborated with major banks, including Credit Agricole, ING, or Vietin Bank in several countries.

The post Payres: deadline buffer for CHAPS ISO 20022 migration first appeared on CCA Europe.

Artykuł Payres: deadline buffer for CHAPS ISO 20022 migration pochodzi z serwisu CCA Europe.

The introduction of the international ISO 20022 Financial Services standard for payments messaging has brought about significant changes in the banking sector also in the UK. The recently introduced New Payments Architecture (NPA) will not only make it easier for many companies and clients in the UK to control their transactions, but will also open many innovational products and services following ISO 20022 migration.

In early July, Pay.UK released the first set of technical materials for organizations heading for ISO 20022 adoption and facing challenges in transitioning to the Next Generation Standard for UK retail payments. For banks and financial institutions, this is the last call to start working on ISO 20022 changes in their IT architecture.

Requirements are complex, as expected

The ISO 20022 standard is an increasingly used format for payment messages. Based on the XML structure, it is already used by payment systems in over 70 countries. The upcoming ISO 20022 migration will have a huge and profound impact on the data carrying capability of payment systems, fundamentally changing the way payments are made and financial information is transferred.

The documentation published by Pay.UK is the first set of industry standardization materials, containing a list of technically difficult changes, as expected. Although preliminary, it is an important step on the way to standardize high-value payments data. Based on the published market infrastructure guidelines, banks that are not direct participants of CHAPS can begin conducting initial impact assessments of the scheduled changes in internal processes and day-to-day operations. Following the adoption of ISO 20022, Pay.UK will require the same changes from its partners as required for financial institutions who are members of the CHAPS system, although in this case the ISO 20022 migration-related deadline is not June 2022, but March 2023. All in the hopes that the end customer avoids any negative impact of the changes in cross-border payments.

Pivotal changes require a proper approach

The scope of changes that banks will need to introduce to legacy systems to avoid negative impacts on customers, operations and market infrastructures is huge. In fact, ISO 20022 migration is broader than any regulatory project in the last 10 years, including SEPA. Therefore, preparation for migration to ISO 20022 will require an experienced IT team, including analysts with in-depth domain knowledge, as explained by my colleagues in this article.

There is some skepticism in the UK as to what opportunities the NPA will eventually bring to financial market infrastructures. Recently, a key stakeholder group raised concerns about the costs, timing, and difficulties of migrating the financial market infrastructures to ISO 20022. In February 2021, the payment systems regulator issued a consultation paper, seeking the views of the banking industry on the best approach to reduce the risks related to NPA implementation.

There are several ways to upgrade the banking IT architecture to accommodate the ISO 20022 standard in financial messaging. A ready-made solution can be deployed as soon as the software vendor launches it, or banks can develop their own solutions in-house. There is also a third option: a financial messaging standards converter as a cost-optimized solution for straight through processing, with more long-term benefits, and our proprietary system, Payres, can be used as one.

ISO 20022 message standard converter that acts as a time shield

Payres supports back office applications that do not support the “common language” of ISO 20022, fully or partially. Our payments messaging broker also allows automated processing of cross border payments exchanged between back office applications and external networks.

Our application not only “translates” messages, but also enables automated exchange of structured data between the bank’s core system and other systems in line with the new messaging standard.

Apart from the financial messaging standard processing, Payres can be used for advanced reporting purposes or trigger a variety of business rules that take effect in external systems. As a result, information that so far has only been processed in a two-dimensional way is leveraged in a number of dimensions and creates competitive advantage for your bank.

Need a budget cushion? Say no more!

It may take some time for the NPA to be thoroughly implemented, and for the benefits of ISO 20022 to be full appreciated. It is possible that all necessary changes required by end of 20022 will not fit into an annual budget or any single financing period. However, with Payres, you can distribute project costs over several such periods, even over several years. If you need support in preparing your legacy systems for the upcoming changes in payment processing, feel free to get in touch!

The post NPA ISO 20022: the game is afoot! first appeared on CCA Europe.

Artykuł NPA ISO 20022: the game is afoot! pochodzi z serwisu CCA Europe.

National instant payment systems are already operational or are being launched worldwide. Banks across Europe are very aware of the need to provide their clients with real-time payments, not only domestic, but also cross-border. In Europe, this presents a certain challenge for the next stage of the evolution of a single euro payments area and real-time banking.

While there is already a pan-European instant payment scheme “SEPA Inst”, as many as 34 markets in Europe have successfully implemented a national instant payment infrastructure, or are now working on one. Oddly enough, the presence of SEPA Instant Credit Transfer makes “real” cross-border instant payments, i.e., those operating both within the euro area and outside it, somewhat complicated.

Two systems of euro-payments

For any bank that transacts outside its home market, connecting to a pan-European system is a strategic priority. However, which path they take is up to them. The two systems that compete in the instant payment market are EBA Clearing RT1 and the European Central Bank’s TARGET INSTANT PAYMENT SETTLEMENT (TIPS) system. How can banks decide which automated clearing solution to prioritize regarding their instant payments, and to which to connect to?

So far, RT1 has more members, 75 to be exact, but it is a closed, membership fee-based payment system controlled by investment banks, with strict testing deadlines. TIPS, on the other hand, does not charge any membership fees and could potentially be open to all banks.

The key difference is the indirect model available for TIPS. It requires the use of the TARGET2 settlement account in the European Central Bank (ECB) but does not require the account to belong to a payment service provider (PSP) or a payment initiation service provider (PISP). Particularly in the light of PSD2 regulations, smaller banks or fintechs may seek partnerships with a sponsoring bank that has an account in the TARGET2 (T2) system. As a result, the scope of TIPS can be much broader than that of RT1, especially given the role of new payment market players in serving the underbanked.

How does TIPS work?

The participating payment service providers are required to maintain the liquidity of a special account opened in the relevant central bank which processes instant payments. Deposits into TIPS accounts are only possible during TARGET2 opening hours.

The following diagram is an outline of how TIPS works:

1. The participant sends a message regarding an SCT instant payment transaction to TIPS.

2.   TIPS approves and reserves the amount to be transferred.

3.   TIPS transfers the payment to the receiving participant for approval.

4.   The receiving participant sends a positive reply to TIPS.

5.   TIPS settles the payment.

6.   TIPS confirms settlement with the sending participant.

7.   TIPS confirms the clearing to the receiving participant.

TIPS aims to encourage payment service providers to join it by enabling them to reach customers at a low cost (the cost of a single transaction in the TIPS system is approximately EUR 0.002). The ECB hopes that instant payments will soon become the default instant payment settlement system across Europe. Then it will also support other currencies to minimize fragmentation in the European retail payment service providers.

RT 1 vs. TIPS: the race is on!

Banks constitute the majority, in terms of both customer number and transaction volume. Therefore, most of the international instant payments will be made in a bank-to-bank system and not necessarily in an external network, at least not in the short term. Therefore, a system which includes as many banks as possible in the euro area, and outside it, is of great importance. These factors could influence the banks’ decision to choose a priority real-time system, thus tipping the scales in favor of RT1.

However, there are risks associated with a relatively closed network. Real-time transactions cannot be offered to customers if there is a high risk that they will be unable to send all payments in real time. Moreover, low availability can cause the service to be terminated altogether due to customer churn. When it comes to instant payment settlement, TIPS seems to be winning the banking budget priority race in regard to joining a pan-European instant payment system.

Given the potential of RT1 and TIPS in terms of coverage, it seems logical for banks to join both systems. However, banks need to consider their complex legacy IT environments, the integration of which is costly. Their fintech competitors are not burdened with legacy technology, and since they are not members of the European Banking Association (EBA), they have no access to RT1. Therefore, they basically have a single payment scheme to consider: TIPS.

Instant money stimulates business

Connecting to the TIPS system and offering pan-European instant payments services is the next step on the way to real-time banking that supports the global e-commerce market. The scope of implementation of TIPS can be small at first due to the low transaction volume, but this doesn’t mean that it will be a low-quality service.

The initial development of pan-European TIPS instant payment services will aim at meeting the needs of the largest and most important corporate clients. However, corporate clients need more than just real-time payments. They need real-time money transfer information, liquidity management, and additional data (BI), as well as the possibility to integrate other systems and message types with it.

The pan-European system does not only concern a new type of payment, but also a new, increasingly global business environment. Any such significant system platform must now easily scale to increasing volumes and integrate with global cross-border payment systems to deliver the quality and reach of services customers expect.

Pan-European instant payments available in 2022?

Europe-wide instant payments can be introduced even by the end of this year. All PSPs that have joined the SCT Inst scheme and are available in TARGET2 should also be available in the TIPS central bank’s money liquidity account.

The upcoming banking transformation will enable taking full advantage of Data-Driven Banking. Currently, we have established an in-house instant payments and ISO 20022 think-tank, to support payment service providers in the European market. Together, we are considering the best ways to prepare our clients and business partners for the upcoming changes in instant payment services. We believe that the banks that are the first to provide their clients with cross-border instant payments will be the winners.

More details on the pan-European instant payments, TIPS (TARGET Instant Payment Settlement) and ISO 20022 payment scheme coming soon.

The post Pan-European instant payments: is TIPS worth the while? first appeared on CCA Europe.

Artykuł Pan-European instant payments: is TIPS worth the while? pochodzi z serwisu CCA Europe.

Enhanced data, new opportunities for financial institutions

ISO 20022 is an increasingly common global language for financial messaging. This standard, based on the XML structure, allows easy data exchange in a flexible standard. Already used in cross-border payments in over 70 countries, ISO 20022 will become the standard for high-value payment systems in the coming years. 

By creating a common language and payment data model, ISO 20022 standard significantly improves data quality across the entire payment ecosystem. Its richer and structured data will open up new user benefits while improving transaction compliance and efficiency, and prevent financial crime around the world. 

The adoption of ISO 20022 standard in the major currency reserve payment systems means that the financial community has agreed to unify payments and reporting between financial institutions. However, the new ISO standard requires the adaptation of banking IT infrastructure. 

In the next five years, the financial industry will face a huge challenge of adapting internal processes and daily operations to ISO 20022 so that these messaging standard changes are not cumbersome for the customer. And since banking system errors have painful consequences for banks, not only in terms of image but also legal, the bar of reliability of banking IT solutions is extremely high. So how should banks plan ISO 20020 migration tests? 

Read the full version of the article on how to properly prepare for ISO 20022 migration. 

The post ISO 20022 implementation: let not the little leaks sink the ship first appeared on CCA Europe.

Artykuł ISO 20022 implementation: let not the little leaks sink the ship pochodzi z serwisu CCA Europe.

Generalist or specialist?

As a CEO, you can decide to either choose a field and deliver very complex projects, or to solve a lot of problems, in many areas, but rather superficially. I believe that the market needs both types of providers. However, specialization allows solving problems of a larger calibre and allows building long-term business relationships. Your partner is aware that this is long-standing cooperation and that you will be able to help them solve the problem now, next year, as well as in two years’ time.

Specialization is also a natural way to create your own products and services. The more you delve into a specific topic, the more you start to see things that could be improved, and the byproduct is a specific product. This is how Payres, our proprietary system for activating banking data in real-time, was created.

Instead of a domain specialization, some companies choose a technological one. For example, the Polish software house STX Next specializes in Python. They consistently build the brand of the largest European Python development company. This label certainly gives them a unique differentiator and distinguishes them in the eyes of both clients and job candidates. Such a strategy can ensure relatively quick niche domination and therefore, global significance in terms of specific solutions.

Pros and cons of specialization

Specialization also has its drawbacks, including recruiting appropriate staff and the possible industry crisis. It requires an extended career path. These days, young people want to be Renaissance men, hence it is more difficult to find people willing to carry out this type of strategy. That is why I am an avid supporter of the T-shaped approach: focusing on a specific domain, with an in-depth understanding of the related topics, complemented by the possibility of using specialists in other fields.

Today, software houses are a bit like film studios. We regularly provide a product, i.e. software, for various projects, based on the joint effort of high-class specialists. This model is spreading to other industries as well. For example, in the construction industry, you will find more and more developers operating as generalists, employing designers or architectural studios that specialize in arranging private or office interiors.

Brand specialization “made in Poland”

The question about the legitimacy of specialization was posed by an association of the programming sector representatives. SoDA already has over 100 members, and their number is growing dynamically, which draws attention to the Polish specialization. There is a chance that a state-of-the-art, well-thought-out code will become a Polish export product.

Poland has already been dubbed “the IT hub of Europe”. In the first quarter of 2018, there were a total of 1,236 BPO, SSC, IT and R&D centres (Polish and international) in Poland, employing a total of 279,000 people. Polish developers are among the best programmers in the world. We have created not only a product brand but also a unique work culture, in which our national determination, persistence and inclination to solve difficult problems has found an outlet.

We need initiatives that broadcast the reputation of Polish developers in the day-to-day “job well done” for foreign clients. In the times of a global pandemic, specialization is worth considering, to prioritize and determine further paths of development in the “new normal”.

The post Generalists or specialists: does narrow specialization pay off? first appeared on CCA Europe.

Artykuł Generalists or specialists: does narrow specialization pay off? pochodzi z serwisu CCA Europe.

Our Profile Automated Testing Tool (PATT) combines the advantages of manual and mass testing. Another improvement of the platform is the integration of PATT with one of the most popular web application testing solutions, Selenium.

PATT says “Check!”

The platform PATT is the result of many years of cooperation between experts with CCA Europe.pl and banking sector institutions. It enables comprehensive testing not only of the FIS Profile software but also other IT solutions beyond reach for classic test automation tools.

The environment allows both running classic automated tests and verifying the data. PATT supports the development and functional tests, but can also be used for integration, acceptance tests, etc. Until now, PATT performed three types of testing operations: SQL – queries directly to the database, MRPC – remote FIS Profile procedures, e.g. creating a new client and ATM – preparing and processing card messages in the ISO-8583 standard.

The application defines commands in a natural language, and the intuitive interface is user-friendly.

A deep dive into banking processes

Running tests on systems inaccessible via the browser level is very expensive and most often done manually. Thus, test automation is typically only done in critical areas.

Previously, to test banking applications, the CCA Europe test team used PATT and the web application testing tool, Selenium independently. Following the two-way integration with Selenium, PATT’s functionalities can be used for comprehensive testing of banking applications. On the other hand, the Selenium functionalities enable designing comprehensive tests for banking processes and drawing meaningful conclusions based on the obtained results.

“Thus far, if the bank has only used Selenium for automation, now it will be able to update its existing test scripts”, explained Jacek Nowak, CEO of CCA Europe. “Integration gives it the missing extra depth. Now it can verify not only the visible effects of the test but also its effects in the core system. As a consequence, it introduces a completely new quality, drastically reducing the risk of problems with the tested software.”

For the first time, integration of these two powerful tools enables end-to-end testing of banking processes – not from the perspective of a single application, but from the banking process in its entirety, which can include multiple applications and is similar to a chain reaction.

“PATT’s integration with Selenium allows accelerating the work of human testers, and moreover reduces costs for the business. What is most important from the end-user point of view, extensive system validation, ensures a reliable representation of the banking process”, says Mateusz Cierpka, Full-Stack Developer at CCA Europe.pl, responsible for the integration project.

Top-class IT standards now available for banking

Thanks to the integration with Selenium, the new solution has a user-friendly interface. It can be used to test a wide range of banking application functionalities and entire banking processes, also in non-web systems other than FIS Profile.

However, to obtain meaningful results, the test parameters must be set correctly. “Properly designing a banking application testing process requires knowledge of banking rigours and areas that require special attention”, said Jacek Nowak, CEO of CCA Europe. “A modern bank is a software developer and must implement the best standards in the IT industry, in line with the approach of continuous delivery and continuous integration. As certified test specialists, we are an independent partner of the bank guaranteeing the reliability of the software produced”, concluded the CEO of CCA Europe.pl.

If you want to learn more about CCA Europe’s comprehensive testing projects and regression testing for banking, both manual and automated, please contact us.

The post Proprietary integration with Selenium opens new testing possibilities for banking first appeared on CCA Europe.

Artykuł Proprietary integration with Selenium opens new testing possibilities for banking pochodzi z serwisu CCA Europe.

Cloud’n’play: the future of banking?

The transition to the cloud is a revolution of a much greater size than the emergence of the core systems 20 years ago. Back then, the leap was contained only inside of the realm of the banking world. Now the banks are transforming in the hope of becoming hubs for all matters of life, not only finances.

This is because In their strive towards improved customer experience, the e-commerce giants such as Amazon or Google have stepped into the realm of payments. They proved that they are technically savvy enough to handle payment processing, and to do it well, i.e. exceeding customer expectations. In response, banks have spotted the red flags and dashed after the runaway train. Their agenda is not only to improve their CX to match that of e-commerce’s, but also to expand their offer with services in such a way that will keep e-commerce at bay. The new standard of banking will include insurance services, investment consulting, or any finance-related service, that Amazon is new to. However, to withstand the competition of agile e-commerce, banks need  more than even a top-class core system. What they need is an entire ecosystem of integrated applications – no longer on-prem, but in the cloud.

In the new ecosystem, each mobile banking application is to bring benefit to the customer and to be standardized. In some time, Apple Store or Google Play will offer several dozen applications meeting all customer needs, not only those related to finance. With standard interfaces, the application can “plug’n’play” into the bank’s IT architecture, regardless of the manufacturer. And when a revolutionary fintech application comes up on the market, a “cloud-native” bank will be able to buy it, connect it to their servers and offer the service to the customer via a plug, available for download in an ordinary app store. 

In my opinion, this is what the banking of the future will look like in the cloud model. The clients “plug” the preferred application package into the architecture of the selected bank, and “uninstall” as they wish. In such an arrangement, the bank will do everything to encourage customers to “plug in” with them, and not with their competition. To retain the customer, the existing central systems must become at least “plug’n’play-ready”, either natively or via adapters. There is only one “but” – no mature central banking system in the world is ready for this yet. 

Is the runaway train worth chasing?

Of course, there are visionary solutions such as @Frank Sanchez’ Finxact, a cloud-native Core as a Service. In March this year, the new digital banking app One and FirstBank operating in western US announced that they chose Finxact to power their services. In late 2019, Finxact launched cooperation with the US Clearing House (TCH) to bring real-time payments capabilities to its customers through the RTP® network, a new payment network financial institutions can use to clear and settle real-time consumer and business payments. 

Finxact initiative is a big leap towards genuine cloud freedom, but it still has a long way to go, as does all the industry. Perhaps, since the system was designed natively for the cloud, its “plug’n’play” features will allow it to supplement any missing functionalities with third party cloud native plugins? In the meantime, what are small and medium-sized banks to do? First of all, they don’t have a core system that could handle cloud solutions well. The solutions available so far have limited functionalities, but over time we can expect core system upgrades to the cloud, with several pre-integrated applications.

FIS, a leading technology provider for the financial world, recently announced that it already has 74 external SLA-guaranteed applications ready for its cloud-ready core system. Still, replacing the core system, or even upgrading its version, is a multi-million dollar investment, which amortizes within a dozen or so years.

When faced with such decisions, banks, especially medium and small-sized, will probably try to patch up the old systems with makeshifts. However, for some operations, these temporary solutions will not be enough. In-house solutions will certainly not be able to compete with the proposals of those players who join ranks with Amazon, Google and Facebook. How will this translate into customer satisfaction? I’m sure the customer will vote with their feet. As a result, within 12 years time, 80% of financial firms will either go out of business or be rendered irrelevant by new competition, changing customer behaviour and advancements in technology, according to forecasts by Gartner.

The giants have enormous money sacks, which they use easily when there is a potential to earn even more in the future. With modern solutions in place, the largest players will be able to adapt to the client overnight, at the same time dividing and conquering the market among themselves and leaving no room for third-party competition. It will impact business partners, customers and IT suppliers of minor players. The question is not if it happens, but when.

Focus on the customer, and not on the chase

However, traditional banking is not without a chance. In its fervor of chasing the next exciting technology the top players can actually lose their touch with reality and the customer will be lost on the way. This is where the banking model based on a proven, long-term partnership has the upper hand. While a part of society feels good about constant change, it is still in the minority, albeit growing. The latter part is focused on stability and gradual evolution. After all, the average length of a relationship with a bank in the UK is 17 years, often longer than a marriage! 

Before the central system vendors are ready with the product and the race leaders reach the “cloud’n’play level”, customer satisfaction is the safest bet. Instead of building virtual worlds, it is worth putting your efforts into a relationship with the client and showing that it is you who is trying harder. There already is a way to genuinely care for the customer, and have them attached enough so that they won’t change ship in the first wave to come as soon as Google Pay offers them a bank account.

How to emerge a winner?

I believe the quick wins strategy is most effective. The clients will feel appreciated when they notice the bank cares for them through frequent, yet not necessarily major, improvements and changes. 

Our proprietary system Payres is based on this idea. It activates banking data in real-time and keeps the customer engaged, or even appreciated thanks to push notifications. The bank is following the e-commerce trends we got us accustomed to – instant response combined with proximity.

The point is not to give up the cloud altogether, but to think about which applications are crucial from the bank’s point of view, and to have them ready when the time comes. Meanwhile, you can consider redirecting the flow of investments from the cloud race to pro-customer solutions. 

If you want to learn more about how the Payres system works, or talk about cloud solutions for banking, do not hesitate to contact me!

Jacek Nowak, CEO CCA Europe

Jacek has been working in the IT sector of the banking industry since 1997, and is a business owner since 2004. He specializes in the digitization of global and local processes related to payment processing, card payments and customer satisfaction. In his limited spare time, he plays board games. LinkedIn profile: linkedin.com/in/jacekvonnowak/

The post A runaway train to the cloud: should medium-sized players join the chase?! first appeared on CCA Europe.

Artykuł A runaway train to the cloud: should medium-sized players join the chase?! pochodzi z serwisu CCA Europe.

Migrating applications, running additional instances, testing or separating them to ensure security and stability jeopardizes the environment’s balance. Do you really have to reinstall the application and restore its configuration every time? What if we need a thousand, or ten thousand copies, or if each instance requires a different IP address? And what if the OS doesn’t include the required dependencies? 

Those kinds of problems are solved with a virtual machine, which can be easily migrated. At the same time, you can adjust resources, assign addressing and isolate the new system from others. But why the whole system, if you only need the application? 

This is where containerization comes into play.

Containerization vs virtualization  

Most of the existing virtualization methods assume a stack consisting of hardware on which the operating system is running, and a hypervisor, i.e. the controller of the next layer: virtual machines. These machines re-use the operating system as the bottom layer of the stack. Above are the libraries and binaries. The application is running at the very top of the stack. 

Virtual machines are isolated from each other, creating a complete and independent environment. The system administrator can adjust the assigned hardware resources quite freely. However, applications running on virtual machines have lower performance than those running on physical hardware, i.e. without virtualization. This is because the virtual machine’s operating system and hypervisor take up hardware resources. Just like a buyer who buys goods via a chain of brokers must take into account higher purchase costs, so each subsequent abstraction layer separating physical hardware from the application depletes its performance. Fortunately, there is a way to lean down the abstraction layers. 

Apps all packed and ready to go

The basic idea of containerization is to place the application, its processes, configuration and dependencies in a virtual unit called a container. From the application’s point of view, these containers are separate and independent instances of the runtime environment. They have a separate RAM and disk space, as well as a private IP address. Despite the isolation, containers can communicate with each other through well-defined information exchange channels.

Containerization allows removing a duplicated operating system and hypervisor, which dramatically reduces the performance gap between the container application and the application running on physical hardware. Simultaneously, it allows the same scalability, portability and instance separation. 

However, please remember that containerization is by no means a successor to virtualization, or some virtualization 2.0. Instead, it is an improved and cheaper way to make the IT ecosystem more flexible, to match individual business needs and make it both on-prem-, and cloud-ready.

Docker, Kubernetes and Docker Swarm

Implementing containerization and then managing such a stack requires an appropriate platform. Undoubtedly, the most well-known and commonly used containerization tool is Docker. It is an open-source solution and a container file format. Due to its popularity, this technology has even become synonymous with the word “containerization”.

When there are more and more containers, and they are deployed on many servers, Kubernetes comes handy. This most popular container orchestration platform was created by Google for its own needs and later released as open-source software. Kubernetes is used to manage, automate and scale container applications. The platform allows managing a large number of containerized application instances and offers a proprietary, integrated form of load balancing. 

Kubernetes enables not only automation but also creating declarative tasks. It is often compared with Docker Swarm, the orchestration software for Docker. The latter solution, although it allows less flexibility, requires much less configuration, offers a faster publishing process and is easier to use. The choice between these two solutions often depends on the preferences of the DevOps team and the needs of the project itself.

SoDA in the cloud

Due to the favourable pros and cons balance, containerization and orchestration are extremely dynamically developing fields of computer science, especially in the face of increasing requirements for business IT.

CCA Europe.pl cooperates with 5 partner companies from the Polish Software Development Association (SoDA) in implementing containerization of applications and migrating applications to the cloud. Each of these companies has its character and specialization. Based on them, we precisely choose the partner’s skill set for a specific project:

1. Specialization: applications, Java technology-based stack and a well-thought-out application development process, in line with Continuous Integration/Continuous Delivery. The partner offers a solid testing strategy based on a standard pyramid, including a Nexus artifacts repository, as well as building Docker Swarm container farms. 
2. Specialization: AWS cloud, including Jenkins CI/CD GitLab Pipelines for running the OS scripts. 
3. Specialization: automatic, performance and stress tests for CI processes. The partner offers consulting services for CI process testing strategies.
4. Specialization: Google cloud, with experience in creating a public cloud. We move Java-based applications to the cloud. Our partner offers Kubernetes certificates for administration and development. 
5. Specialization: MS Azure cloud. The partner offers full coverage of the CI/CD process with Azure DevOps and Azure Pipelines with Jenkins, GitLabs, Bamboo or Concourse, when applicable. Both Kubernetes and Docker Swarm can be freely selected. We use Azure Artifacts or Artifactory as an artifacts repository. We specialize in migrating applications to the cloud in the .NET stack, but we also have experience in application environments based on other technology stacks.

With containerization, microservice farms on cloud platforms are possible. They enable not only easy migration of applications but also virtually unlimited adjustment of the resources to load used. 

With partners demonstrating such a wide range of competences, we can implement even very advanced CI/CD processes or migrate applications to the cloud.

The post Software containerization: IT’s money box first appeared on CCA Europe.

Artykuł Software containerization: IT’s money box pochodzi z serwisu CCA Europe.