ISO20022 — THE PAYMENTS REVOLUTION

Gareth Lodge April 2015

CONTENTS

Executive Summary ............................................................................................................ 1

ISO20022 — The Future Of Payments? ............................................................................. 3

Of Payments and Standards ........................................................................................... 4

What Is ISO20022? ......................................................................................................... 4

Where Is It Being Used, and How? ................................................................................. 5

The Case for ISO20022 Is Clear ......................................................................................... 7

Remittance Data .............................................................................................................. 7

Global Interoperability ...................................................................................................... 8

Lower Cost of Ownership ................................................................................................ 8

There Are Some Adoption Challenges to Address ............................................................. 9

Awareness and Understanding ....................................................................................... 9

Traditional Business Cases Are Hard to Build .............................................................. 10

Not All Standards Are Standard .................................................................................... 10

Greater Infrastructure Demands .................................................................................... 11

Implications for Banks ....................................................................................................... 13

Plan for Message Size Growth ...................................................................................... 13

Plan for Accessing Messages ....................................................................................... 13

Not Storage, But Management ...................................................................................... 14

Path Forward ..................................................................................................................... 15

Leveraging Celent’s Expertise .......................................................................................... 17

Support for Financial Institutions ................................................................................... 17

Support for Vendors ...................................................................................................... 17

Related Celent Research .................................................................................................. 18

EXECUTIVE SUMMARY

There are events that are seismic in impact, that redefine the landscape. Think about how the Internet combined with mobile technology has altered our expectations to wanting “everything, everywhere,” whether at home or at work. The events that are most impactful are those where change has previously been rare, unexpected, and game changing. It’s not hyperbole to say that the payments industry is going through exactly that at the moment with ISO20022. Europe was at the epicenter, but the shock waves are spreading rapidly. The question is no longer if ISO20022 will impact you, but when.

Payments is the one thing that unites every consumer and every corporate, in every country. Everyone has to make payments, and so it comes as no surprise that making that as efficient and as safe as possible has been a critical focus. Standards play a vital role in this process. Yet while we may all recognize payment methods from another country, the reality is that under the hood, they work in different ways and utilize different standards. That makes making a payment to another country, something we take for granted on a domestic basis, extremely difficult.

At the same time, payments have been a very standardized business for a very long time. Banks need to ensure they are using common formats, in the same way, to ensure the seamless movement of money. The downside of this is that many of these formats have been around for a very long time and were designed at a time where computing looked very different. As a result, many of these formats are very simple, and rarely carry all the data that would ideally be passed in the payments message. For example, the UK Standard 18, the UK ACH format, is so called because no field is longer than 18 characters. Therefore not only is there no extended remittance information in the message, the field name itself (“Remittance field”) is too long to fit in the field!

This situation could obviously not continue forever. The new IBAN addresses in some countries were significantly longer than the message formats could contain. A message format has emerged that looks to not only be the solution to this problem but also provide significant additional advantages. As a result, while just over a decade old, it is now the most widely used payment standard, globally, and its growth is accelerating.

This format is ISO20022, and many consider it to be the future of payments.

This paper has two main purposes.

First, to provide insight into what ISO20022 is — and isn’t. A number of markets are close to adopting ISO20022, most visibly Canada, but the US looks close behind. Yet a study in 2012 showed that only 9% of US respondents were aware of ISO20022.

Second, to educate banks that have adopted ISO20022 about key challenges and opportunities that they will face. Even in markets that have adopted ISO20022 messages, such as Europe with its SEPA formats, there are lessons that only become apparent when something is used at scale. Previous ISO20022 implementations have been small scale, measured in the millions of transactions. SEPA sees all ACH transactions in all Euro countries start to use ISO20022 messages. That means now billions of transactions a year are being processed. As a military strategist once said, “No plan survives contact with the enemy.” Only now have some of the challenges and opportunities started emerging.

Chapte

r: E

xecu

tive S

um

ma

ry

2

ISO20022 has a number of aspects worth noting. Being an XML-based message, it is extremely flexible, and can carry as much — or as little — information as the scheme wishes. As a result, many banks need to ensure that they have chosen a solution that can manage the potentially significant increase in the size of the payments message. That’s not just the processing, but what is then done with the payments. Increasingly banks need to access the payments data for reporting purposes. This implies a data warehouse alone may not be sufficient, but that banks need to be able to curate the messages, rather than store them, to ensure access at speed and with flexibility.

Banks have long assumed that only software built for banking is suitable for banking. Yet many other industries have also had to address the challenges around data that banks are increasingly facing. In particular, the telecom industry has very similar challenges to the banking business: high volumes of transactions, priced in very different ways, that need to be itemized on bills at a later date. Elsewhere in the bank, this connection has been made, with many of the recent billing implementations in banks and processors utilizing solutions originally from the telco industry. The same applies for price optimization tools. Banks therefore ought to be looking to high-volume data businesses to see what those organizations are doing, and seeing this as an opportunity for improvement, rather than simply a task that needs fulfilling.

This report was commissioned by IBM, at whose request Celent developed this research. The analysis and conclusions are Celent’s alone, and IBM had no editorial control over report contents.

Chapte

r: I

SO

200

22 —

The

Futu

re O

f P

aym

ents

?

3

ISO20022 — THE FUTURE OF PAYMENTS?

ISO20022 has now been in existence for many years, and seems to be destined to be the future of payments. Yet it is still widely misunderstood, both in terms of what it is (and isn’t) and what it can (and can’t) do. Understanding this is critical for any country considering adopting ISO20022, and increasingly for any bank, regardless of whether the industry in its country is adopting it as a standard. Many banks have already adopted ISO20022. Furthermore, many of the new processing technologies, such as Payment Services Hubs, use it as their native internal format.

So why write this report now?

There are two key reasons.

First, possibly the largest ISO20022 implementation, SEPA (Single Euro Payments Area), has now gone live. The focus to date has been about just that — going live; Celent believes that there will be a focus going forward on living with it. One specific issue has not been widely discussed: the likely explosion of data associated with ISO20022 and how best to manage it.

Second, the largest payments market in the world, the United States, seems to have edged yet closer to formally adopting ISO20022 messages. In 2013, a consortium of banks commissioned a study to look at the business case for adopting the standard. While the report concluded that there was no financial case, it did, however, state that it believed there was probably a strategic case. This was followed by a series of documents and consultations by the Federal Reserve, looking at what improvements that the US payments industry might undertake. While much of the discussion has been about the potential for a faster payments system, the scope was broad. In January 2015, the Federal Reserve released its latest document, titled “Strategies for Improving the US Payment System,” where it outlined five strategies which it believed would deliver the improvements it seeks. It is worth highlighting two of the strategies:

Strategy #2 – Identify effective approach(es) for implementing a safe, ubiquitous, faster payments capability in the United States (beginning in 2015)

Strategy #4 – Achieve greater end-to-end efficiency for domestic and cross-border payments (2015 and beyond)

Develop an implementation strategy for the application of the ISO 20022 standard to US payment transactions.

Accelerate adoption of secure electronic business-to-business (B2B) payments.

Develop technologies and rules that foster greater interoperability for person-to-person (P2P), person-to-business (P2B) and small business B2B payment directories.

In prior research, Celent has discussed the fact that ISO20022 is increasingly the default format for real-time payments. Coupled with the explicitness of Strategy 4, US banks need a better understanding of what ISO20022 is and what it might mean for them.

Chapte

r: I

SO

200

22 —

The

Futu

re O

f P

aym

ents

?

4

OF PAYMENTS AND STANDARDS Payments are at the heart of banking, and have existed for hundreds of years. Standards have been needed from the very beginning. One of Sir Isaac Newton’s early achievements came when he worked at the Royal Mint in London. In 1699 he introduced the milling around the edge of the coins, and decreed that there be a uniform size and weight to coins, thereby ensuring that they were all standard. A simple step, copied by many countries around the world. However, as we all know, the coins in each country are different — different sizes, different materials, etc. They may all be of a standard size and shape for that country, and use the same principles and approach, yet no two countries’ coins are the same.

The evolution of electronic payments sees the same story. At a high level, they are the same; they have a value, a payor, a payee, a date, etc. Yet the standards vary tremendously, as they have evolved to meet local requirements, themselves a product of history and time. The UK standard for ACH payments is known as Standard 18, not because it was the 18

th standard created, but because the maximum length of any field

was limited to 18 characters. When it was created in the 1960s, the standard needed to work on the IT and telecom infrastructures of the day, and 18 characters was deemed the balance that transmitted enough data while preserving scarce bandwidth. Even in more recent and more international standards such as ISO8583, used for debit cards, significant domestic changes have been made at a domestic level to ensure it met local needs. Indeed, at the start of the SEPA programme, over 200 elements of the “standard” were found to be unique to a small number of countries, but not standard across Europe.

This is not to criticize those standards. They were designed for a purpose, and have served those processes well for decades. Yet times have moved on in terms of technology, needs, and opportunities. For example, as corporates move from paper to electronic payments, they seek to have the same levels of remittance information, something that would be impossible in a standard created in the 1960s. Furthermore, as international trade becomes more and more widespread, the difficulty in making payments across borders efficiently highlighted the need for a new, common standard. For many people, this is what they think of when they speak of ISO20022, yet it has the potential to be so much more.

WHAT IS ISO20022? It is interesting to see just how many misunderstandings there are about ISO20022 — that it is, among other things, a Swift standard, an ACH payments standard, a cross-border standard, and an XML message. All of these are in part true, but don’t tell the whole story. The benefits become more evident when we describe more accurately what it is and some of its uses.

ISO20022 is essentially a standard of standards for the financial industry, a common way to develop messages. It started life in the 1990s as ISO15022, and covered just securities initially. It wasn’t until 2004 that it was broadened to what we think of as ISO20022.

ISO20022 defines two key things: the use of syntaxes and the use of different semantics. Understanding these key concepts, and how they differ from existing payment standards, is central to understanding ISO20022. They separate the payment format and the business rules for what is in the payment.

The syntax describes what many would be familiar with as the format. In theory it could be used with a wide range of formats, but the majority of ISO20022 implementations use XML as their syntax. The benefit of this approach is that, should something come along later which proves to be better than XML, the only thing that would change would be the syntax — the semantics would remain constant.

Chapte

r: I

SO

200

22 —

The

Futu

re O

f P

aym

ents

?

5

The second advantage, and the key one, lies in semantics. ISO20022 decouples the data description from the data format. Mention a specific payment standard, and those familiar with the standard will know exactly what is meant by the terms. Yet take one step away, to even a same payment type but from a neighbouring country, and not only will they not know what is meant, but the terms may even be different. For example, debtor, payor, ODFI, and sender are all used for — broadly — the same description. ISO20022 sets a common vocabulary for all to use. These then are the business rules or semantics. By defining the semantics, everyone has a common understanding of what is meant and how it is used. This is the reason why ISO20022 is so powerful.

WHERE IS IT BEING USED, AND HOW? ISO20022 is being used much more broadly than many people think. Although it is synonymous with SEPA payments, ISO20022 is being used as the basis of many financial services standards. Indeed, it was initially a securities standard primarily, but is used in five distinct areas (known as business domains): payments, securities, trade services, foreign exchange, and cards.

Table 1: Implementation of ISO20022 Is Not Just Limited to SEPA

BUSINESS DOMAIN LIVE

ROLLOUT/ TESTING

PLANNED UNDER

DISCUSSION TOTAL

Payments 26 3 7 3 39

Securities 13 1 15 1 30

Trade Services 2 0 1 0 3

FX 0 1 0 0 1

Cards 1 0 0 0 1

Total 42 5 23 4 74

Source: ISO20022.Org

There are 74 different projects monitored by ISO20022.Org, the registration authority. While there are live or nearly live projects across all five domains, as shown in Table 1, it is clear that the largest number of projects are in the payments domain. Furthermore, the reason ISO20022 is so closely linked with SEPA is that SEPA is by far the largest project using the standard.

SEPA actually describes a political goal, rather than one specific project. The goal is encapsulated in the acronym: Single Euro Payments Area. The goal is for a consumer or corporate to have a borderless Europe — that is, in any Eurozone country, to be able to make a payment that can be processed in any Eurozone country. That requires a common language and understanding, and the reason why ISO20022 was adopted. As previously discussed, each country’s systems and processes differ. Indeed, in some forms of direct debits, for example, different information flowed to different actors in different directions. The payment types that were created needed to be carefully thought through, to ensure common understanding and common goals. The resulting payment types — SEPA Credit Transfer (SCT) and SEPA Direct Debit (SDD) — have, since August 1, 2014, replaced the legacy payment types in the 19 Eurozone countries. That affects more than 38 billion transactions per year. The remaining countries in Europe have until October 2016 to migrate all the euro payments that they make to SEPA formats. Given that the volumes are far smaller and have less impact, many of these countries have already completed that migration.

Chapte

r: I

SO

200

22 —

The

Futu

re O

f P

aym

ents

?

6

In addition, some of the other projects, particularly in the trade services domain, are designed to leverage the work done in SEPA. For example, the use of ISO20022 as an e-invoicing standard is designed to make a seamless end-to-end transaction, rather than “just” a payments transaction.

Second, while some of the other projects are closely linked to SEPA, ISO20022 is in use globally. Many of the projects are multinational in focus, so counting projects at a country level results in a much higher number. Table 2 counts the 74 projects shown in Table 1 at a country level and then groups them at a regional level.

Table 2: Implementation of ISO20022 Is Not Just Limited to Europe

REGION PROJECTS

Africa 49

Asia 46

Europe 250

Middle East 7

North America 15

South America 9

Source: ISO20022.Org

Interestingly, while Europe dominates, there are large numbers of projects worldwide. The table hides as much as it reveals, however: the proportionally larger number of countries in Africa and Asia perhaps overstate the number of actual projects. That said, there are some projects that are Africa specific. Southern African Development Community (SADC) is developing a number of initiatives that will utilize ISO20022 to enable different cross-border initiatives, including for mobile payments.

Chapte

r: T

he

Case f

or

ISO

2002

2 Is C

lear

7

THE CASE FOR ISO20022 IS CLEAR

REMITTANCE DATA ISO20022’s most often quoted benefit for corporates is remittance data. Remittance data is the data that is about the payment. It specifies what the payment is for, by including reference numbers, descriptions, purchase order numbers, etc. That's one of the reasons why many US corporates believe that checks remain the most useful method because the sender can include a letter with all the appropriate information in the same envelope.

In theory, an ISO20022 message can carry extensive, if not unlimited, remittance data, which would allow the corporate to automate the reconciliation of its payments. For both the sender and receiver, that has definite cost savings. Yet the reality is that the US ACH system has had the ability to send some remittance data since the 1980s and extended remittance data via XML since 2010. The challenge is that unless every step of the process can handle the extended information, then it will be truncated to the maximum length that can be handled. And the reason that many US corporates have yet to move from checks is with the remittance data itself, not the payment. The Association for Financial Professionals (AFP) carries out a regular survey on adoption of electronic payments. They regularly ask what the barriers are to greater adoption. In the most recent survey in 2013, five factors were selected by at least two-thirds of all the respondents, shown in Figure 1.

Figure 1: Barriers to Adoption of Electronic Payments

Source: Association for Financial Professionals Electronic Payments Survey, 2013

Surprisingly, in the 2004 edition of the survey, the majority of respondents gave almost exactly the same answers. It is Celent’s belief that remittance will be the key benefit for corporates over time, but that isn’t the case today, nor is it enough on its own to drive adoption. It also means that corporates need at the very least to be able to create and unbundle ISO20022 messages. This is one of the reasons why SEPA included two mandates: first, that the ISO20022 message be used end-to-end, meaning that banks weren’t allowed to convert from existing formats, thereby ensuring that the data at least

Chapte

r: T

he

Case f

or

ISO

2002

2 Is C

lear

8

got passed. Second, they restricted the number of characters in the remittance field to 140, making utilizing the field easier.

GLOBAL INTEROPERABILITY At first glance, the benefits of this are obvious. ISO20022 becomes the Esperanto of the business world, allowing payments between countries. The reality is that this vision is a distance off yet. While it is growing rapidly, it is still a long way off being even considered widespread, let alone ubiquitous. Yet the advantage of ISO20022 is that it doesn’t need to reach that level of adoption to still be useful. It has a further advantage, acting as a bridge between standards. An increasing number of standards, such as EDI-FACT and TWIST, are being mapped to ISO20022. That enables translation between differing standards by using ISO20022 as a bridging standard, even if the originating and receiving parties don’t use ISO20022 themselves.

LOWER COST OF OWNERSHIP ISO20022 provides many cost savings; a few are notable. First, there is a greater availability of software providers. Many legacy systems were created by domestic systems providers, as they required domestic, proprietary software. Technology vendors therefore decided whether to invest in those standards based on the potential of the market. As a result, choices are often limited, and costs potentially higher as a result of the lack of competition. Given the global nature of ISO20022, there are immediately significantly more products and providers available.

Second, given the larger number of vendors, there are typically more fixes available, and the vendors are more likely to be responsive in supplying fixes because they impact their entire client bases, not just one market.

Related to this, the whole point of using XML is that changes that in proprietary format would require significant work may simply require mapping in XML, something the client could do. That provides much more future-proofing of ISO20022 as a standard (and therefore the tool sets) than a proprietary format.

Finally, given the overall move to standardization, there will tend to be fewer technical issues, such as the need to convert formats, coupled with the fact that fewer formats and standards will need to be supported over time. This has significant benefits in terms of time to market and costs associated with testing.

Chapte

r: T

here

Are

So

me A

do

ption C

ha

lleng

es t

o A

ddre

ss

9

THERE ARE SOME ADOPTION CHALLENGES TO ADDRESS

There are many positive aspects to adopting ISO20022, but there are a number of issues associated with it as well. Some of these are perhaps best described as lessons learnt; equally, Celent believes there are certain issues still to emerge.

AWARENESS AND UNDERSTANDING One driver for this report was to increase understanding of ISO20022, but it is worth highlighting the impact of awareness. For many in the industry, ISO20022 has been widely discussed, and has been one the staple discussions on the agendas of many of the main banking conferences. Outside of the banking industry — even just outside, such as at AFP — awareness falls away dramatically.

The benefits that can be accrued, such as greater remittance data and fewer formats to support, will make a difference to corporates. In regions such as Europe, where the SEPA formats are mandated end-to-end (as opposed to being just an interbank standard), corporates have had to become aware. Yet, in major economies such as the US, awareness is negligible. A survey in 2012 carried out by the Federal Reserve Banks of Minnesota and Chicago found that only 9% of corporate treasurers were even “somewhat aware” of ISO20022. The danger is that, while corporates may adopt ISO20022, they will see it as just another standard to be complied with, thereby missing the chance to fully reap the benefits.

Figure 2: Familiarity with ISO20022 Among Business Practitioners, 2012 (n = 468)

Source: Remittance Coalition, 2012

Chapte

r: T

here

Are

So

me A

do

ption C

ha

llenges t

o A

ddre

ss

10

TRADITIONAL BUSINESS CASES ARE HARD TO BUILD The biggest single barrier to adoption is that of building a business case. While many of the strategic benefits are clear, that doesn’t necessarily mean that they equate to tangible, short-term benefits. This applies to almost all standards, and is the reason why many, if not most, standards fail to reach ubiquitous adoption. As more than one person has said, don’t worry if you don’t like this standard — there’ll be another along shortly.

Adoptions fall into two types, new and replacement. The business case for a new adoption is somewhat simpler, as benefits are baked into the larger project. For example, many of the recent installations of real-time payment systems have utilized ISO20022 as the underlying standard. Indeed, in some markets such as Poland, the move has only been possible because of the standard. The Polish community had initially wanted to use the card standard ISO8583, but realized that Polish IBAN numbers were not only longer than the 16 digits defined in ISO8583 but also varied in length.

A replacement project requires not just new technology but also changes in business processes, and the benefits will not accrue unless a significant number of counterparties adopt at the same time. If they don’t, the corporation will be supporting two systems. That's been one reason why many of the projects have been industrywide — adoption by a single bank will have benefits, but they’ll be much smaller than if the whole market adopted. So added to the complexity of the business case is the challenge of getting market consensus.

NOT ALL STANDARDS ARE STANDARD Most national payment standards have been in place for years, if not decades. As a result, they are very uniform; that is, deviation from the standard is usually an error. At a national level, this is very easy to control. In many countries, the largest five banks account for over 70% of the payment volumes.

At an international level, standards still tend to be fairly consistent. Swift MT messages are used globally, with only a few local tweaks and variations about how certain fields are used.

In both instances, that is because of strong control and governance over the scheme. This doesn’t exist in ISO20022 to the same extent. Some argue that this is one of the strengths of the approach, in that it is neutral and has no bias to any one type of business or industry. The standards body which manages the scheme ensures that it meets the requirements to be accepted, but it doesn’t enforce that they are being used correctly.

This leads to two potential complications.

The first, which should disappear over time, is the interpretation of new schemas. The best example here is that of SEPA. The SEPA scheme aimed to take the best part of all the existing schemes. As such, it looks like no existing scheme. To ensure a smooth transition, an extensive set of rule books were written collaboratively by the industry. Yet, there are known to be as many as 180 variations already in existence. Some will end up being incorporated or addressed in future releases of the rule book, but many others will need to be addressed and removed. These are often related to legacy processes and therefore legacy technology. The sooner they are removed, the sooner the legacy technology can be retired and the cost savings realized.

The second is potentially more serious. In theory, any group can submit a potential schema for adoption. To succeed, they’ll need to adhere to the rules that the committee defines. In essence, the committee is ensuring that they adhere to the common language that is defined. What perhaps is missing is how these schemes work together. With disparate use cases and geographies, there is a danger that distinct dialects emerge.

Chapte

r: T

here

Are

So

me A

do

ption C

ha

llenges t

o A

ddre

ss

11

The parties will be able to converse, but not without the pause for the thought or clarification, which tempers the benefits of the approach.

The combination of the two has a multiplier effect, a many-to-many relationship, or worse, a case where only certain schemes are supported, or where there becomes a belief that it’s not actually standard.

GREATER INFRASTRUCTURE DEMANDS This final section covers those issues that occur on implementation. The first two issues have been widely discussed, and to an extent, understood. Both are related to the ability for a message to hold unlimited information.

Bandwidth and Processing It should be noted that, while in theory it’s unlimited, nearly all current implementations limit the size of the fields. For example, in SEPA formats, the remittance information is limited to 140 characters. This is considerably longer than many of the legacy formats that it is replacing. It ensures a consistency and predictability in file size — by limiting the fields and field lengths, it creates a maximum message size. For planning purposes, this is important, because it allows designers to estimate how much processing power is going to be required. As the file is significantly larger than other formats, there has generally been a need to increase bandwidth and processing power to cope.

Dutch banks found, for example, that the new direct debit file was approximately three times larger than the legacy standard (Clieop03). This meant each transaction now averaged 0.5 mb in size (including the message container). Compression is possible, and can dramatically reduce the file size by up to 98%, but the same solution is required at both ends. That’s feasible within a group, but given the cross-border nature of SEPA, unlikely at a European level. At the same time, it’s not just about the size in kb that is the issue, but also the numbers of characters. The SEPA format allows for some fields to be up to 140 characters in length, whereas previously it may have been limited to just 18 — or indeed, the field may not have existed at all.

This cost is generally analogous to upgrades required for increases in volumes. This cost itself is often offset over the longer term by the fact that many systems now use ISO20022 as their internal format (the case for a number of payment services hubs, for example) and the wider availability of IT fixes, and cheaper ongoing costs, such as the reduction of the number of standards supported. This means not just less expertise, but equally it becomes simpler and less error-prone to swap between the remaining formats, resulting in fewer exceptions being generated.

Storage The final point in this section seems to have been widely overlooked, but we believe will be increasingly important to address. That is the issue of what to do with the messages in terms of storage. We use the phrase storage as opposed to warehouse or database, as there are a number of facets to consider.

In many cases, the reason for being overlooked is often explainable. In most instances, the adoption has come as part of a much wider program, which comes with its own challenges and deadlines. SEPA was a huge, multi-year project, and a number of deadlines were missed because of the size and complexity of the task. As a result, in most instances, the approach was to essentially replicate existing approaches. As a result, many banks have replicated their existing payments data warehouses. There are a number of potential issues with this approach.

First, there are questions about scalability. The messages are significantly larger, and so the storage requirements are significantly larger than their legacy messages. This means, regardless of any other factor, the storage requirements are going to be at least the ratio

Chapte

r: T

here

Are

So

me A

do

ption C

ha

llenges t

o A

ddre

ss

12

of ISO20022: legacy format. That also implies greater storage in terms of backup and in terms of processing power of accessing that data. One of the promises of ISO20022 is the ability to use the greater level of data to generate greater levels of insight from the messages.

The second issue is that many of the data warehouses are payments data warehouses. That is, they are designed with that process and use in mind. Given the vision of extending the financial supply chain by using interoperable messages, there would seem to be benefit of storing the messages in one place, rather than a trade finance data warehouse, a securities data warehouse, etc. That would suggest the warehouse is designed around the facets of ISO20022 (and most probably, XML) rather than the process. A single database will mean lower overheads, from operational support to licence costs. Linked to that is a potential benefit for those organizations considering a payments modernization programme. One of the key aspects in the building of these is deciding what falls within the payments utility, and what falls outside. If the store can be delivered as a service to the payments system, there is a strong rationale for having it outside the utility, as it can then be decoupled from the payments processing, and it can be utilized by other processes outside the payments domain more readily. For example, one of the growing areas of concern is the cost of revenue leakage. This is where prices are incorrectly applied (for a variety of reasons) or not applied at all. The store then could become a key component of the billing process. That in turn could present opportunities to deliver the contents of the messages to end clients or partners (such as correspondent banks) via a portal.

The third issue is the data benefit from a single store, which Celent believes will include some large advantages. It will give a single customer view of messages, and so customer insights and billing should be improved. It should create a more efficient store. Each message will have some data that is common to many, if not all messages — the bank name, for example. These fields can be more efficiently stored, by pointing to a reference field, rather than the entire contents of that message. That may only be a fraction of a saving, but some banks, particularly multicountry banks, could be storing billions of messages a year. Payment volumes are forecast to grow in volume in excess of 4% a year, and for some payment types, such as debit cards, 10% a year; the savings before even adding in the other use cases for ISO20022 could be substantial.

Chapte

r: I

mplic

ations for

Banks

13

IMPLICATIONS FOR BANKS

PLAN FOR MESSAGE SIZE GROWTH For all banks, the initial planning phase will be deciding how to tackle the increase in file size. What follows looks at Europe, but serves as an example of what will happen in other markets.

For smaller banks, while it’s a significant jump and a headache, it “just” requires planning for them in some ways, because bigger banks already manage larger numbers of payments. That is, they will have the choice of solutions that the bigger banks already use. For big banks, the challenge is more significant. In most European countries, banking is very concentrated, with the largest five banks accounting for at least 80% market share. This usually equates to approximately their share of the payments market as well. At a European level, while there are 19 euro countries, just seven (ranked in order, Germany, France, Spain, the Netherlands, Italy, Austria, and Finland) account for 95% of all ACH payments made in the Eurozone. This means that, of the thousands of banks in the region, less than 35 banks are likely to process 29 billion payments, and those messages are now approximately three times larger than they were previously. Assuming the Dutch example in the previous section is correct, that’s approximately 12TB additional storage that those 35 banks will require in 2014. Assuming an annual growth of 3% per year, that equates to 150TB additional storage over the next decade.

This is not all bad, given the ability to compress files — indeed, the Dutch example is actually slightly smaller when compressed than the compressed legacy standard. In reality, with the right compression solution, banks may actually be able to reduce space requirements. Yet compression capability is not the only aspect.

PLAN FOR ACCESSING MESSAGES Storing data is only half the battle for banks. Many banks argue that big data is not an option for them, because they struggle to utilize the data they already have. The pressures to use that are increasing, and will only continue to do so. Indeed, many regulations are already requiring greater use of the information in the payment. For example, in SEPA, there is a right to instant refunds for up to eight weeks after the payment, and up to 13 months for unauthorized transactions. The new regulation BCBS248 is for meeting intraday liquidity monitoring requirements for payments. Given the growth of real-time payments, and that most systems are being built using ISO20022, increasingly data from the stores will be used to generate reports for regulatory reasons.

This creates a number of issues. First, can the data be stored quickly enough? This will be a key determinant for banks of any size, but particularly larger ones, as they see growth in real-time payments which are generally single message. While storage options may exist, many are designed more as archives and run on a batch basis. That means they may not necessarily be optimized for continually storing individual messages, throughout the day.

Second, and something Celent suspects will become increasingly important, can the data be audited? Banks will increasingly need to be able to ensure that the integrity of the data is both intact and auditable.

Third, given that all the data has account-level detail for both the payee and payor, is the store secure? Account take-over fraud has been an issue in some countries, but with the advent of real-time payments, those risks rise greatly. For example, access to the

Chapte

r: I

mplic

ations for

Banks

14

payments data highlights which accounts have large volumes of payments, and the values moved indicate the accounts most likely to be of interest to the fraudster.

NOT STORAGE, BUT MANAGEMENT Given these aspects, banks need to be more actively managing their payments data, even if they don’t plan to do anything more with the data than they currently do. Data no longer needs to be stored, but curated. That requires a fundamentally different approach.

Banks, and payments specialists in particular, have tended to assume an “Only a banker would know” attitude. There’s been an assumption that only solutions designed specifically for banks will be fit for purpose. Yet a number of banks are now beginning to wonder if that's just not true, and is perhaps part of the problem. For example, payments is one of the last adopters of cloud technologies, yet (given its cost base and fluctuating processing demands) stands to gain most. Other industries arguably process data at least as sensitive as payments data, yet adopted cloud processing nearly a decade ago.

By looking at other industries, banks may not only find potential solutions out there, but also discover things that they could be doing. It may be worth turning to the telco industry for the answer, for example. The telco industry generates huge amounts of data — calls, with differing rates and rate plans, texts, etc. — which have to be presented and used to generate bills. But to the broader point, many of the leading billing solution providers began life in the telco space, as did the price optimization vendors. These two examples alone have had significant positive impacts on the payment space and are now widely accepted as the industry norm.

Chapte

r: P

ath

Forw

ard

15

PATH FORWARD

ISO20022 has far to go, but in the decade since its creation, has come a long way. The impact on banks is clear. ISO20022 is used, or is being discussed, in 74 projects in 90 countries. Some of those projects, such as SEPA, are processing in excess of 38 billion transactions per year. In short, ISO20022 is becoming the global financial services payments standard. It’s doubtful it will ever be the only standard, but it is probably already the most widespread, after card standard ISO8583. Yet the impact is far greater, creating the opportunity for an end-to-end set of messages that underpin the entire procure-to-pay process of the corporate. Making that process as frictionless as possible has enormous value to the corporates; that in turn brings enormous opportunity to banks.

Banks therefore need to start looking at ISO20022 in a much more strategic way, with a roadmap of where they are heading and the tools that they will need to get them there. There are a number of things to consider in particular.

First, every indication suggests that, while a long way off from being the only standard, it is rapidly becoming the dominant standard. Banks need to start analyzing what impact adoption would have on them. How ready are they? Do existing systems have the capability of handling them now, and if not, what will it take? This applies to banks that already handle ISO20022 messages. Many have converted from existing processes, without taking a long-term view of the impact. As such, even SEPA-compliant banks may have issues that they need to review because the pre-deadline volumes were a fraction of the volumes that are now being processed. Given the growth in electronic payments, are banks going to be facing curation and archiving issues sooner than they had anticipated?

Second, when should they move? There are three parts to this.

1. What likely market events might trigger an industry move, such as SEPA did in Europe? In many countries, particularly in the US, this is likely to be the introduction of real-time payments.

2. Is there first mover advantage? Some banks, such as Deutsche Bank, believed that being SEPA ready — and therefore ISO20022 ready — as soon as possible (and indeed, before deadlines had been set) as having strategic advantage to them, and invested in the appropriate technology.

3. What are my peers doing? A number of banks have moved simply because their peers have. There are a growing number of US banks that are now able to create SEPA messages, as they now only require a single banking partner to reach every consumer and corporate in Europe.

Third, how does a bank maximize the benefit? This is more about thinking about ISO20022 less of a standard, but more of an enabler. Will it enable the banks to create a common database of all ISO20022 messages? Would doing so drive greater benefit and insight for both the bank and their customer? We believe few banks have done much on this particular point, creating potential differentiation for those banks that have.

Regardless, all banks have to have a view on ISO20022, at the very least, with a clear vision of the opportunities ahead and the requirements to reap them. It’s more than the future of payments — it’s the future of financial services.

Chapte

r: P

ath

Forw

ard

16

Was this report useful to you? Please send any comments, questions, or suggestions for upcoming research topics to info@celent.com.

Chapte

r: L

evera

gin

g C

ele

nt’s E

xpert

ise

17

LEVERAGING CELENT’S EXPERTISE

If you found this report valuable, you might consider engaging with Celent for custom analysis and research. Our collective experience and the knowledge we gained while working on this report can help you streamline the creation, refinement, or execution of your strategies.

SUPPORT FOR FINANCIAL INSTITUTIONS Typical projects we support related to payments include:

Vendor short listing and selection. We perform discovery specific to you and your business to better understand your unique needs. We then create and administer a custom RFI to selected vendors to assist you in making rapid and accurate vendor choices.

Business practice evaluations. We spend time evaluating your business processes. Based on our knowledge of the market, we identify potential process or technology constraints and provide clear insights that will help you implement industry best practices.

IT and business strategy creation. We collect perspectives from your executive team, your front line business and IT staff, and your customers. We then analyze your current position, institutional capabilities, and technology against your goals. If necessary, we help you reformulate your technology and business plans to address short-term and long-term needs.

SUPPORT FOR VENDORS We provide services that help you refine your product and service offerings. Examples include:

Product and service strategy evaluation. We help you assess your market position in terms of functionality, technology, and services. Our strategy workshops will help you target the right customers and map your offerings to their needs.

Market messaging and collateral review. Based on our extensive experience with your potential clients, we assess your marketing and sales materials—including your website and any collateral.

Chapte

r: R

ela

ted C

ele

nt R

esearc

h

18

RELATED CELENT RESEARCH

IT Spending in Banking: A Global Perspective February 2015

IT Spending in Banking: A North American Perspective January 2015

Integrated Receivables Vendors: Celent ABCD Vendor View January 2015

Noncash Payments: Global Trends and Forecasts, 2014 Edition December 2014

Receivables in Motion: The Changing Game Plan to Grow Treasury Management Revenue November 2014

Real-Time Payments: Case Studies from Around the World September 2014

Payment Services Hubs Revisited: Lessons Learned September 2014

Real-Time Payments: Dispelling the Myths August 2014

Treasury Management: Origins and Directions July 2014

Top Trends in Corporate Payments: 2014 Edition May 2014

Celent Model Bank 2014, Part 5: Case Studies of Innovation in Cash Management April 2014

Celent Model Bank 2014, Part 4: Case Studies of Payments Innovation April 2014

Copyright Notice

Prepared by

Celent, a division of Oliver Wyman, Inc.

Copyright © 2015 Celent, a division of Oliver Wyman, Inc. All rights reserved. This report may not be reproduced, copied or redistributed, in whole or in part, in any form or by any means, without the written permission of Celent, a division of Oliver Wyman (“Celent”) and Celent accepts no liability whatsoever for the actions of third parties in this respect. Celent and any third party content providers whose content is included in this report are the sole copyright owners of the content in this report. Any third party content in this report has been included by Celent with the permission of the relevant content owner. Any use of this report by any third party is strictly prohibited without a license expressly granted by Celent. Any use of third party content included in this report is strictly prohibited without the express permission of the relevant content owner This report is not intended for general circulation, nor is it to be used, reproduced, copied, quoted or distributed by third parties for any purpose other than those that may be set forth herein without the prior written permission of Celent. Neither all nor any part of the contents of this report, or any opinions expressed herein, shall be disseminated to the public through advertising media, public relations, news media, sales media, mail, direct transmittal, or any other public means of communications, without the prior written consent of Celent. Any violation of Celent’s rights in this report will be enforced to the fullest extent of the law, including the pursuit of monetary damages and injunctive relief in the event of any breach of the foregoing restrictions.

This report is not a substitute for tailored professional advice on how a specific financial institution should execute its strategy. This report is not investment advice and should not be relied on for such advice or as a substitute for consultation with professional accountants, tax, legal or financial advisers. Celent has made every effort to use reliable, up-to-date and comprehensive information and analysis, but all information is provided without warranty of any kind, express or implied. Information furnished by others, upon which all or portions of this report are based, is believed to be reliable but has not been verified, and no warranty is given as to the accuracy of such information. Public information and industry and statistical data, are from sources we deem to be reliable; however, we make no representation as to the accuracy or completeness of such information and have accepted the information without further verification.

Celent disclaims any responsibility to update the information or conclusions in this report. Celent accepts no liability for any loss arising from any action taken or refrained from as a result of information contained in this report or any reports or sources of information referred to herein, or for any consequential, special or similar damages even if advised of the possibility of such damages.

There are no third party beneficiaries with respect to this report, and we accept no liability to any third party. The opinions expressed herein are valid only for the purpose stated herein and as of the date of this report.

No responsibility is taken for changes in market conditions or laws or regulations and no obligation is assumed to revise this report to reflect changes, events or conditions, which occur subsequent to the date hereof.

For more information please contact info@celent.com or:

Gareth Lodge glodge@celent.com

AMERICAS EUROPE ASIA

USA

200 Clarendon Street, 12th Floor Boston, MA 02116

Tel.: +1.617.262.3120 Fax: +1.617.262.3121

France

28, avenue Victor Hugo Paris Cedex 16 75783

Tel.: +33.1.73.04.46.20 Fax: +33.1.45.02.30.01

Japan

The Imperial Hotel Tower, 13th Floor 1-1-1 Uchisaiwai-cho Chiyoda-ku, Tokyo 100-0011

Tel: +81.3.3500.3023 Fax: +81.3.3500.3059

USA

1166 Avenue of the Americas New York, NY 10036

Tel.: +1.212.541.8100 Fax: +1.212.541.8957

United Kingdom

55 Baker Street London W1U 8EW

Tel.: +44.20.7333.8333 Fax: +44.20.7333.8334

China

Beijing Kerry Centre South Tower, 15th Floor 1 Guanghua Road Chaoyang, Beijing 100022

Tel: +86.10.8520.0350 Fax: +86.10.8520.0349

USA

Four Embarcadero Center, Suite 1100 San Francisco, CA 94111

Tel.: +1.415.743.7900 Fax: +1.415.743.7950

Italy

Galleria San Babila 4B Milan 20122

Tel.: +39.02.305.771 Fax: +39.02.303.040.44

China

Central Plaza, Level 26 18 Harbour Road, Wanchai Hong Kong

Tel.: +852.2982.1971 Fax: +852.2511.7540

Brazil

Av. Doutor Chucri Zaidan, 920 – 4º andar Market Place Tower I São Paulo SP 04578-903

Tel.: +55.11.5501.1100 Fax: +55.11.5501.1110

Canada

1981 McGill College Avenue Montréal, Québec H3A 3T5

Tel.: +1.514.499.0461

Spain

Paseo de la Castellana 216 Pl. 13 Madrid 28046

Tel.: +34.91.531.79.00 Fax: +34.91.531.79.09

Switzerland

Tessinerplatz 5 Zurich 8027

Tel.: +41.44.5533.333

Singapore

8 Marina View #09-07 Asia Square Tower 1 Singapore 018960

Tel.: +65.9168.3998 Fax: +65.6327.5406

South Korea

Youngpoong Building, 22nd Floor 33 Seorin-dong, Jongno-gu Seoul 110-752 Tel.: +82.10.3019.1417 Fax: +82.2.399.5534