Potential Legal & Compliance Issues with Post-Purchase Transaction Matching in 4-Corner Receipt…

Sun, 03 Jan 2021 02:47:38 GMT

Read the original article...
Go back to Xiippy Blog and News Articles

Potential Legal & Compliance Issues with Post-Purchase Transaction Matching in 4-Corner Receipt Delivery

Banks are trying desperately to catch up with modern payment solutions and include itemized lists of goods and services (e.g. receipts) as attachments to transactions in a 4-corner receipt delivery model via an intermediary. However, if not done correctly, sellers will have to disclose all itemized sales data to intermediaries regardless of customers’ consent. This means they must seek consent from “all” their customers before doing so at the counter. There are better ways to do this which does not require explicit consent collection. Read on to know more…

A Little About Xiippy…

https://Xiippy.ai is the world’s first and only 1-step in-store and online data-rich checkout provider with end-to-end encrypted privacy-preserving smart receipts and personalized rewards.

Xiippy supports multiple methods to deliver pre-payment invoices, post-payment receipts and rewards points that do not involve any change in consumers’ behavior or extra steps.

We deliver receipts and rewards to all cards of all types, irrespective of their issuers or country. We do not depend upon bank integration to operate an d we do this with end-to-end encryption which helps us stand out as we maintain zero knowledge of receipts, sales data and purchase data.

At Xiippy, we make all the benefits of enriching transactions with data via invoices and receipts available to buyers and sellers without actually having access to such data, resolving adoption barriers and protecting privacy in the process, which is our unique offering.

We also offer banks (or other invoice/receipt consumers like retailers’ own apps) client-side SDKs and an oAuth2/OIDC based authorization model to allow such parties to make calls on our users’ behalf, get authorized and get access to users’ receipts relevant to them but we do this only at client side since we don’t have access to consumers’ receipts in plain format on our infrastructure. If a user does allow a 3rd party have access to their receipts by sharing with them the relevant private keys, they certainly can do this, if it adds value to them.

At Xiippy, we pride ourselves to tackle complex problems like the one this article proposes.

What surprises us though is how banks are showing this to be a simple problem.

Itemized Receipts for Transactions — The Problem

The fundamental issue is that traditional payment protocols, most importantly EMV, have not been designed to include a list of items sold or bought as meta data attached to the transaction. There were clear reasons for this though, which include the followings:

Reason 1: Consumer’s privacy and businesses’ confidentiality & information protection

There was and still is no basis on the request from banks to disclose to them what businesses are selling and what people or businesses are buying just for the sake of convenience. Banks have nothing to do with invoices and receipts which are legal documents belonging to the seller and buyer; banks have things to do with payments (i.e. how much, from who to whom at what time) and that is what exactly the payment protocols cover.

Reason 2: Implementation complexities, tamper-resistance and non-repudiation

Much of the crypto and effort in the EMV protocol is focused on one simple fact: to make sure counterfeit cards are detected and transactions remain valid. There is a significant amount of work built into the protocol to make sure the details on the chip card are the details the issuer put in them and that they are valid. This implies that the protocol has been built around the fact that via buyers’ cards, the buyer is a provider of information — with information being the details that the bank has set on their cards — and that such information must be verified with regards to correctness.

Most importantly, these protocols have not been designed to cover cases where the merchant also provides verifiable details like invoices or receipts.

Once digitized, anything can happen to data. Imagine someone showing up claiming that they have a digital receipt showing they have bought an item from a merchant without that actually having happened. There has to be checks and balances in place.

All authentication mechanisms in EMV (e.g. online ones using Application Cryptograms (TC, ARQC, or AAC), and offline data authentication (ODA) (i.e. static data authentication (SDA) and dynamic data authentication (DDA)) make use of symmetric or asymmetric crypto keys created by the banks and embedded in the chip card at the time of issuance to verify the data a card reader terminal receives from a card is the one that the bank embedded in the card at the time of issuing the card.

If it was desired to embed verifiable details from the merchant in the protocol too, this would mean some sort of key management and distribution mechanism had to be devised so that such keys would be used to verify that the data provided by the merchant (i.e. the receipt or invoice) are also valid.

This part is half the battle Xiippy has resolved with its patented receipt delivery scheme and is logistically challenging and can hardly be done in an offline fashion hence no one was thinking of it with traditional protocols!

Much of our effort at Xiippy.ai has been focused on this aspect. To make sure invoices and receipts remain undisputable and tamper-resistant.

What we are not sure of is whether or not these startups banks are betting on have thought of this aspect deeply enough!

Alternative: 4-Corner Receipt Delivery with Post-Purchase Transaction Matching Via an Intermediary

With the challenges of updating payment protocols the right way, alternate options are on the table. In one of such options, the POS treats the transaction the same and requests a payment from the payment terminal or alternate options, however, after that, it uploads the receipt via some basic APIs to a 3rd party intermediary which will also receive data from banks, helping the intermediary match what bank transaction the receipt relates to. The bank will, in return, receive the matched receipt and demonstrates it as an attachment to the transaction for the relevant user, and treats the data according to their privacy policy (Klaus Fuchs et al., 2019), as depicted in Figure 1 below.

Figure 1 4-corner receipt delivery based on transaction matching

What Can Be Wrong?

GDPR, CCPA and other similar legislative frameworks have a very simple purpose. They want to put order in place and ensure people are aware, in details, how their information is being used and to whom it gets disclosed.

There are players out there that have left the consent collection challenge to the bank. Basically, they imply that the data they receive from the banks only includes the relevant transaction details belonging to only those users who have consented to this scheme. But what is not clearly discussed is whether or not the retailer should also get consent from the customer, at the counter, whether or not they are happy for their receipts to be sent to the intermediary and the bank.

In the end, it is a 4-corner model which means other than the seller and the buyer, there are 2 other players: the collector and the distributor, to both the data gets disclosed. One cannot receive all the sales data and claim they are discarding the pieces for which they don’t have consent.

Overall, if the retailer does not clearly ask the customer that their receipt is about to be disclosed to two more parties, and they do submit the receipt to APIs automatically, irrespective of customer’s consent to their banks, they may well be in breach of GDPR and other similar regulations for those users who have not provided consent to their banks, or those who may not have been asked about this at all but the scheme sends their receipts to the intermediary (to be rightly discarded). This issue can expose retailers to fines and unwanted consequences. Either way, as long as the intermediary receives receipt data, customers must be informed and their consent must be acquired.

This immense level of effort to avoid having to ask customers questions or change consumer behavior is simply not aligned with GDPR or similar legal frameworks, if it is intended to send customers’ data outside of a businesses’ premises or data centers.

What Is the Right Way to Do This?

First and foremost, we believe the right way to transfer and aggregate private legal information like receipts is the end-to-end encrypted way. Essentially, a zero-knowledge model where the inherent and under-appreciated privacy of paper receipts can be matched with the intermediaries AND the banks remaining unaware of the data.

And if someone says “the whole value of this is with the data”, our answer is that via applying edge computing and distributed privacy-preserving machine learning, our patented approach already makes the value of data available to its real owners: the seller and the buyer, not anyone in between.

In our patented receipt and statement delivery scheme, we have designed a mechanism where data does not get disclosed to the intermediary and this resolves the need to collect consent from the user at the counter.

To achieve this, we have had to use cryptography. It has been much more complex than just saying “we are trustable parties and we dispose of the data that we don’t have consent for”, instead of saying ‘only pass to us what you have permissions for’.

See, when privacy-by-design is used as a design principle, everything automatically aligns with GDPR and the like. Unless the user authorizes a party, no data becomes available in plain format to be consumed by that party. Zero-trust is always the best option to take!

The Xiippy.ai team


Johannes Hübner, Klaus Fuchs, Fabian Schmid, Bedrija Hamza, 2019. Digital Receipt Study: Drivers and Barriers to Adoption of Digital Receipts, available at https://www.autoidlabs.ch/projects/digital-receipts-for-the-consumer-iot/