Why should banks care about ISO20022?

 Consider some of this data:

-Total transition costs for migration to ISO 20022 payment message standard cost the SEPA $9 billion as per a 2017 study.

-Payments Canada expects a migration from checks will save the Canadian economy $4.5 billion.

This is good for the economy and society as a whole but I am a bank running for profit so why should I care? I have a system that works fine, the inefficiencies and delays in my current system is to my benefit as I can enjoy the float and charge more plus its been working fine for decades.

Well too bad, bank. Customers and regulators are insisting on this change and if you don't change you risk rising operational costs. falling behind the curve leading to loss of customers and regulatory burdens.

Lets peel this onion, shall we?

Rising operational costs: Drop in STP rates means less and less of your transactions will be completed without manual intervention. As it is, only about 60-80 % of your transactions go through STP and this is already  impacting the cost vectors of your payment business. ISO20022 rich data messaging allows you to do better reconciliation leading to improved STP rates.

Regulatory burdens: Sanctions screening, AML, KYC, purpose of making the transaction, legal entity, ultimate beneficiary  all these are checks you are doing today. With tools like LEI in ISO20022 this information travels with the message reducing your regulatory obligations.

Loss of customer: If I am a customer expecting a wire transfer and its going to take a week to get the money in my bank account and cost me $40 for this  , I will certainly look for options to get the funds faster and for lesser cost. No brainer here.

So the cost of not moving to ISO20022 is not the factor .Rather, it is the when and what deadlines I am facing that drive this decision. See this chart and note that many market players in North America are yet to go live but be assured all regulators are working in this directions.

Read More

The Data Management Challenge

 Data data everywhere , not a bit to use  can become a familiar story in banks as our sources of data such as ISO20022 information , internet of things (IoT) with every edge device capable of a payment transaction and scads of video, biometric  and other unstructured data. Banks have done a good job of gathering all this data but very few know where it is or how to use it.

Here are the issues:

-Keeping up with storage and use for consumption by analysts and data scientists.

-Why is the data being collected ? Few know why and how it will be utilized and whether it can be even used . But the pile of data keeps growing because we collect everything.

-Lack of process to understand and index queries. Monitoring this growing pile from different sources also requires  indexing the most frequent data. The risk is these data lakes can turn into data swamps without a rigorous process to manage this aspect

Thank you GDPR and CCPA! By making the consumer a stakeholder in the management of their own data  while imposing real costs to banks for failing to obtain data without proper consent, having poor controls on use of data and if they cannot erase it on request , these laws have given banks the opportunity to rethink their data management strategy.

Read More

Customer minutes and friction as a metric for Banks

 Everywhere we see especially in ecommerce what used to be complicated method of paying for goods and if required getting refunds used to be fraught process. Nowadays Amazon has shown the way with One click ordering and refunds.

This consumer focus to help make their lives easier while interacting with a machine has been rewarded both by customers and the stock markets . What are some examples where banks have made the difference?

- Transaction alerts on the mobile app 

-Customer authentication on the phone if calling from a registered number

-Servicing via chat if customer is on the online banking portal.

These use cases showcase how to reduce friction by reducing "Customer minutes" i.e. time spent by customers to address their issues. Think of how the internal business processes have been rejigged to permit these outcomes.

ISO20022 rich payment messaging data is a building block for enabling these types of friction reductions in business and the real benefit is in terms of better cash flow and the opportunity to innovate on top of the payment message data set.

Read More

Banks cede innovation in Retail Payments

 We have seen the great uptick in new methods of payment initiation by the customer. Examples of these are:

-QR Codes

-Request to Pay

-Pay by mobile phone and other devices using Google or Apple Pay

-Buy now Pay Later or Installment Pay.

-EMT or email money transfer

All these new services are can be grouped as Alternative Payment Methods (APMs). These services are possible by layering an Alias Directory on top of the payer, payer's bank, the network, the payee's bank and the payee. Overlay services delivered via the alias directory improve customer experience at all touch points like POS, online commerce etc. . Where the network is a real time rail, account to account settlement is possible much like a peer to peer network thus reducing interchange costs and delays associated with traditional market infrastructure.

Where are the banks in all this? Nowhere!

All of these services have been delivered baring EMTs by non bank actors or fintechs. Why?

These newer players did not have legacy costs recovery to worry about nor to fight "we have always done it this way at our bank" mindset. They also took the customer for granted.

Now these trends are hitting the banks at the core where they have no place to hide: the large corporates demanding these services and if they don't provide these corporate accounts will shop around. 

 The customer payment initiation battle is lost, so what can the banks do ?

Read More

What is LEI?

 LEI stands for Legal Entity Identifier . This is a 20 character alpha numeric code based on ISO 17442 standard. This code helps in identifying the legal entities in a payment transaction. 

For example in Canada all counterparties to the derivatives transactions need to have an LEI. As faster payments and pay mod initiatives kick  in, more market participants including legal companies, their subsidiaries, government departments, charities will be expected to have this code.

The LEI Common Data File Format v.2.1 is expected to record previous legal names, "operating under", "brand name", "trading as". This clarity is expected to reduce operating cost and false positives.

In future once LEIs are incorporated into the business processes substantial cost savings accrue  in verifying entity during loan origination, KYC refresh, credit worthiness monitoring , compliance reporting etc.

Banks can consider using LEI as a business case to step up the ISO20022 modernization effort.

Read More

The Age of Open Banking

 Let us pivot for a moment from the back office of ISO20022 payment messages to the front office where the customer meets the bank.  Imagine your legacy bank has worked hard to modernize its payment systems and now carries rich data about a transaction end to end.

What challenges do banks face? Several in fact. 

Sharing Customer Data: Who do I share this data with?  What is the risk to the bank, the customer? How is my API strategy shaping up?  Regulations are spotty at best and cant be depended to course correct us.

Partner: As a bank, I don't know the use cases of the rich data I am bringing, so let me partner with a third party. While I do benefit with customer acquisition is it damaging  my brand? Do I promote my APIs to anybody or restrict it and if so what do I restrict ? Case in point--TD Bank sued Plaid recently. 

Plus and minus points to consider such as how will the data be used by the third party and what risks arise to me as a custodian of this data. Key benefits of my product are a convenient way to compare accounts, some financial services and loans. Will price comparison benefit me or not? Upside is my sales channels and distribution increase. What are the downsides?

Distributor: In addition to my own products as a bank I can resell third party products like mortgage calculators, education and tools around budgeting for example. This leads to better customer journey. But what if the third party leaves and goes to another bank? Case in point--Mogo bank account origination was with one bank and they flipped to another--in this case Mogo is reselling the partner banks' balance sheet leading to some basis points yield but customer information is with Mogo so who has more value?

No easy answers here. Lot depends on the assessment of your capability as a bank to go to the market, what are your strategic goals near term and whether a Partner or Distributor model has buy in of the executives.

 

Read More

How to use data from ISO20022?

 

 

The attraction of ISO20022 messaging data is:

-It is unambiguous: the meaning of each data element is known

-It is credible: the origin point of the data is known.

-It is consistent: all ISO messages follow a standard that is universally understood.

 

These factors lend itself to data analytics at scale. Many banks have data lakes and initiatives to use AI/ML to develop insights. The building blocks are in place.

What is payments data?

Data generated by providing payment services such as card payments, mobile payments, debit and credit transfers, ATM transactions etc. The type of information about the persons doing the transactions collected are PII data, sort and account codes, payment date and time as examples. Enriched data that is not necessary for payment processing such as location, mobile device id, cookie for online store, channel, frequency of use are other features that can be incorporated while developing insight from the payment data.

Use case for these analytics

-Internal

Operational efficiency such as cash loading cycle for ATMs, designing reward programs for encouraging a specific banking channel, loan underwriting feeds, better AML/KYC to start with and these can go deeper as the bank becomes familiar with exploiting the use cases and repurpose for other areas

-External

Developing premium products such as integration to corporate ERP systems for real time cash flow analysis, treasury collateral forecasting, sharing purchasing behaviour with customers is helpful for predicting seasonality in purchase, value or impact of a promotion or sale offers. These offerings build deeper touch points with customer and ring fence the customer from competition by fintechs.

 

 

 

Read More

Brief on ISO20022 CAMT Reporting

 

 

Under the ISO20022 payment messages for credit transfers, direct debits and electronic payments will all need to use the same standards, languages, procedure, and format to be compatible. The new format is called CAMT for Cash Management. CAMT ensures the customer a continuous XML process from submission through to the account statement with no disruption and specifically covers Bank to Customer Cash Management reporting

The three most relevant CAMT formats for payment processes are listed below:

• camt.052 – Electronic Account Report

This bank-to-customer account report will provide you with information on all transactions and entries. The camt.052 will enable you to control your cash assets and take advantage of interest on credit balances. This is your intraday information and provides the customer with a near real time view of their accounts. The camt.052 replaces the Swift MT942 Interim Transaction Report.

• camt.053 – Customer Statement

This bank-to-customer statement provides you with the required information about your entries. With camt.053, you have detailed, exact, and organized information on all entries for your prior day. The camt.053 is an alternative to the MT940 Customer Statement Message.

• camt.054 – Bank-to-Customer Debit/Credit Notification

The camt.054 format provides you with specific account debit and account credit information on all transactions entered on your account. The reports in camt.054 allow you to carry out the processing of individual transactions entered on your account as a total figure. The camt.054 replaces Swift MT900 Confirmation Debit, and MT910 Confirmation Credit messages.

Form payments to reconciliation the business process is enhanced in CAMT. CAMT reporting enables consistency, moving towards a standard where banks populate the information in a specific and defined manner since there are specific tags to report specific information.

 

 

 

 

Read More

ISO20222 and Straight through processing (STP)

The main benefit of ISO20022 rests on the fact that it will allow higher STP throughput. Let’s peel this onion a little bit.

What we know:

-The ISO 20022 standard defines a methodology for the development of financial message standards.

- It relies on UML3 (Unified Modeling Language) models representing financial business processes, flows and transactions in a neutral notation.

-These business transaction models are then subsequently converted into physical messages in the desired syntax, like XML (eXtensible Mark-up Language).

- ISO 20022 defines the methodology for encapsulation business transactions and the data dictionary that is required to support those transactions. For example, a financial message can be completely compliant with ISO 20022 but be expressed as fixed width record layouts or API-based constructs such as JSON.

 

So what?

UML offers a standard way to visualize a system’s architectural blueprints and associated components like actors and activities.

What it means is:

-Take a business process such as a payment or securities instruction between parties.

-Break it down into the flow of information between the parties and/or systems (the actors)

-Think of an instruction sent (an activity), followed by status updates, a notification of settlement and a final end-of-day statement.

-Next,  break down into the components that define the information required, for example what is a currency, what is an account, etc.

Conclusion:

The result of the exercise is that you end up with a “Repository” of base business definitions that underpin all compliant messages that adhere to the standard. The advantage of this is that anyone who wants to create a compliant message is at liberty to call the elements what they like, but by linking them to the base types in the repository you can be sure that all parties involved in the processing of the message will have a common understanding of what a currency or account is and what its format is. This represents a major building block for effective inter-organization STP (Straight-Through-Processing) of information.

References:

www.volantetech.com

Read More

Compliance a Concern for Banks migrating to ISO20022

As ISO 20022 becomes more prevalent as a message standard of choice, banks are wrestling with the compliance risks that come with implementing this standard.

 

For the last 40 years a name and address in Swift MT consisted of 4 lines of 35 characters each. MT focused on concise information as opposed to clarity since it was developed in the days of low bandwidth and leased data lines were every expensive. In addition, over the last few years there has been the requirement of AML screening against sanctions lists and enhanced KYC including more information about LEI, names and addresses of beneficiaries. Further, the MT formats only support a Latin syntax whereas the rise of Asian character sets like Chinese are required nowadays.

 The ISO 20022 message definitions specified by payment providers include more data than the corresponding MTs used in cross-border business. If an ISO 20022 instruction is converted to MT for a cross-border leg, there is a risk of data being dropped or truncated. This creates compliance concerns because dropping data in end-to-end payment processing is unacceptable. Incomplete data, truncated data, false positives around sanctions lists all lead to increased regulatory burden for banks. The cost of investigation of errors and customer service grows proportionally. 

Banks must consider several thousand man-days of effort to ensure the data flows seamlessly. Some areas they will need to look at:

 -Legal Entity Identifier reference look up database 

-Source data for KYC with more accurate data capture at payment origination point. 

-High value system gateway updates 

-Updates from clearing system need to have a process to manage and apply the changes periodically

-Support of ISO20022 data, XML middleware, storage, and security

Read More

Understanding ISO20022 Message Types

 

So what is the fuss all about? Currently the transaction related information is sent in legacy formats (e.g. SWIFT MT) and that is expected to change with the use of ISO20022.

Let us look at the different message formats and where they are used in ISO20022. These formats will cover debit, credit, mandates, settlement, investigations and statements to name the key ones. In ISO 20022’s naming scheme, message type is described with four letters followed by three sets of numbers.

 

Message Type:

Pain.001 or Payment Initiation—this depicts a credit transfer message. It can also be used for payment of salaries and checks. Other message versions are also being published by ISO.

Other message types include Camt (Cash Management and Reporting) and  Pacs ( Payment Clearing and Settlement)

The tables below summarize the different types of message formats

 

Customer and Bank
Payment	Pain.001	Pain.002	Pain.007	Pain.008
Mandates	Pain.009	Pain.010	Pain.011	Pain.012
Overlay Services
1.       Request to Pay	Pain.013	Pain.014
2.       Enhanced Data	Remt.001	Remt.002
Payment Reporting	Camt.052	Camt.053	Camt.054

 

 

Interbank Payments
Payments	Pacs.002	Pacs.007	Pacs.008	Pacs.004
Settlement	Pacs.009	Pacs.010	Pacs.002
Reporting, Admin	Camt.052	Camt.56	Admi.0nn
Investigations	Camt.029	Camt.030

 

 

Now that we understand the different message types lets look at this chart from SWIFT to see how a legacy MT message is mapped to an ISO20022 message.

 

This is the first challenge:

-To understand what systems are impacted by the new standard

-How to map the legacy message to ISO20022.

Read More