In Bills And Statements Are Hard To Decipher, we noted that it was very hard to read bills and statements from banks, ecommerce companies, retailers and other industries. We took two examples and did a deep dive to understand the full extent of the indecipherability problem:

1. Ecommerce Bill
2. Bank Statement

In this post, we will examine the root cause of this problem and propose a few solutions.

----------

There are a few characteristics of bills and statements - more precisely, of the systems that generate them.

Systems of record have limitations 

Back in the day, email systems supported only eight characters for the ID (i.e. the name that appears before the @ symbol in an email address). As a result, people had to truncate their first name and last name to fit into the ID. Ergo there were email addresses like ravindrn@microsoft.com (my cousin, who was one of the first 2000 employees of Microsoft) and anilgods@ibm.com (my customer, who is an IBM veteran). (Both emails changed to protect identity.)

Likewise, even today, many systems of record have character length limitations for various fields e.g. SKU description in order entry and inventory systems. I suspect this constraint caused the poor readability of the ecommerce bill in the first example.

Billing systems are downstream

Bills and statements are not created from the ground up. Instead, they're put together from data pulled from suround systems in the IT landscapes of banks, etailers, and companies in other industries. Ergo they're subject to the old adage of computer science: GIGO - Garbage In, Garbage Out. While redesigning bills and statements can improve their look-and-feel, it cannot solve the fundamental readability problem caused by cryptic / missing / garbled text received from upstream systems.

Surround systems straddle multiple companies

This problem is exacerbated when the aforementioned "surround systems" traverse multiple companies, as it happens with bank statements. The multiplicity of systems that includes core banking, digital banking, channels, payment service providers, and scheme operators, causes additional readability challenges as follows:

1. Cryptic messages entered by end users in free form text fields e.g. memo field in which the payor enters the purpose of payment. (In Australia, some customers regularly use this field to send abusive messages to ex-spouses!)
2. Leakages, limitations, and garbling of data by upstream systems.
3. Disconnects caused by the multiple protocols used for messaging between different systems e.g. ISO 8587, SWIFT MT, ISO 20022. Each protocol has its own attributes in terms of field length, support for special characters, and so on. As a result, the narration entered by the payor in his bank's system is not necessarily the narration seen by the payee in her bank's statement of accounts. I suspect this resulted in the indecipherability of the bank statement in the second example.
4. Same as above for different products e.g. ISO 8587 for ATM, SWIFT MT for Cross Border Payments, ISO 20022 for Waiting for Godot. As a result, the narration seen by the payee varies by the method of payment e.g. NEFT narration is different from IMPS narration even when the payor has used the same narration from his side while initiating both MOPs, as highlighted in Enhanced Remittance Data Could Multiply Electronic Fund Transfer Volumes.
5. Insufficiency of data due to restrictions imposed by data privacy laws on the type of data that can be handed off by one system to another. This is particularly true in regulated industries like healthcare e.g. EHR will display full case history to every treating doctor but limited case history to pharmacies.

Because of these peculiarities, entries in bills and statements are shaped by the quality and quantity of data in source systems.

This makes it virtually impossible for ecommerce companies, banks and others to assure the readability experience of the overall bill / statement by themselves. (For more or less the same reason, bank reconciliation is not as simple as generally believed.)

----------

It's tempting to believe that etailers, banks, PSPs, technology vendors, and scheme operators can sit together and redesign their systems such that the aforementioned issues are curbed at source.

But industry insiders would know that this belief is close to the fond hope of ex-Vice President of USA, Dan Quayle, at the height of Arab-Israel conflict a few decades ago:

Why can't the Jews and Arabs sit together and settle their differences like Honest Christians?

That's because such a redesign program would cost a lot of money and fail to deliver proportionate returns.

VC-backed etailers are under no pressure to make profits and might undertake such a program.

However, banks - who fund VCs - are under severe pressure to post quarterly profits and generally don’t spend too much brainpower or moneypower just to prevent their customers from scratching their heads. Although, from time to time, they do pay lip service to making their customers' life easy via initiatives that somehow never seem to see the light of the day e.g. ISO 20022, Enhanced Remittance Data in UK.

https://twitter.com/s_ketharaman/status/1581280694076346369

----------

Whenever there are legacy problems, startups are ready to jump in the fray to solve them and thereby gesture to disrupt the incumbents.

Readability of bills and statements is no exception.

They're egged on by VCs in this pursuit.

@rajeshsawhney: Banks don’t innovate. A bit of thought and a simple redesign of bank statements can add so much value and delight.

However, as we saw above, indecipherability is not an easy problem to solve.

It's only when startups build systems and try to integrate them with core systems that they realize how badly they have underestimated the extent of the readability problem.

One of the following two things happens from there on.

Liquidity is high, the startups get enough funding to solve the problem. Exhibit A: PayPal.

@gtm360: Ignorance may be a virtue for startups in many regulated industries. As Reid Hoffman once said, "had we known about credit card fraud rules, we wouldn't have founded PayPal".

Liquidity is low, funding dries up before they solve the problem, VCs move on to another industry, and these startups fold up. Exhibit A: Personal finance manager (PFM) startups that tried to classify expense types into various categories based on entries in bank statements. But they were thwarted by poor readability of statements from banks, funds, brokerages and other financial institutions. Bereft of this killer feature, they failed to go mainstream.

----------

But all is not lost.

There's a new genre of ETL startups that promises to use advanced AI / ML techniques to improve the quality of data ingested by downstream systems e.g. FlatFile and OneSchema.

AI / ML is highly domain specific. If these ETL tools work on systems of record in banking, ecommerce and other industries, they might finally be able to solve the indecipherability problem and take the readability of bills and statements to the next level.