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

Cost and Value in Payments

 Today cross border payments have a reputation for high cost and lack of transparency in the fee structure.

Coupled with a 600 year old system of Vostro/Nostro accounts and Correspondent banks as middlemen the system is opaque as best and takes 5-7 days for settlement to conclude.

Where are these costs coming from? This graphic from Payments Canada will help.

Can fintechs help reduce costs? See this graphic from RBC in one of their pilot studies with Ripple 

Dramatic reduction in costs and speed yes. But real life is not a tech project. SWIFT with its network of 10000 banks, each node in the network has painstakingly negotiated contracts and SLAs , regulations in each jurisdiction have to be understood and compliance has to be managed.

The solution is ISO20022. The vision is end to end payment messaging with rich data to overcome barriers in speed, compliance and processing costs.

Read More

Value of digital transformation

 

Customer onboarding at Visa

Customer onboarding at Plaid

Visa paid $5.3 billion for Plaid. What does this tell us about the potential for digital transformation and embedded finance with ISO20022?

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

Case for ISO20022 migration

 

Its not about a technical specification and the fact that a lot of data travels with the payment in ISO20022.In making a business case for migrating to ISO20022, its very hard to sell to executives why a change of this magnitude is desirable. I collected a couple of data points both for the bank and its customer to showcase why this migration is desirable.

 

For Bank:

Banks have a very complex legacy architecture that has served them well for most part. However, the cost of servicing failed STP payment transactions is becoming prohibitive.

In Singapore for example a 60% STP rate is the norm. What is the norm for your bank? Is it acceptable? Factor in costs for false positives in sanctions screening. The business case can be built around these two cost factors as a starting point.

 

For Customer:

An Insurance company for example can expect 400 invoices to be paid in 10 payments. If the bank can provide enriched data about these invoices and payments the reconciliation effort is substantially reduced. The reporting around this information can be built into the value proposition.

 

What if the bank does nothing?

Over time the legacy infrastructure burden will render the bank unable to compete even if there is time available to migrate to ISO20022. The bank may have to start somewhere, perhaps look at message translation options as a starting point.

 

The way to build the business case will be in terms of operational costs, customer servicing and mandate timelines coming from bodies like SWIFT and country specific modernization deadlines.

 

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