The Difficulty of Cross-Organizational PII Verification and ‘Confirmation of Payee’

Let’s dive in and discuss why making one organization’s customer data verifiable for another one is a difficult and awkward problem to solve

Key Points

· Privacy regulations prohibit organizations like banks, that are custodians of their customers’ private data, to freely share such private data with other organizations without collection of consent

· There are cases where organizations need to verify the private details of other organizations’ customers, e.g. a payment process for Confirmation of Payee

· The easy-looking solution of establishing data sharing treaties between firms and countries, regulative manipulation to facilitate data sharing, establishing centralized trusted intermediaries to share data with and get help from for verifying details or collection of customers’ consent are actually very hard to execute, making them inconveniently-bad solutions.

· Alternatively, zero-knowledge privacy-preserving techniques are the only option that are easy to execute and do not depend upon such difficult inconvenient pre-requisites

Regulations

Legislatively, organizations like banks, telecommunication companies, universities and government agencies, that are the custodians of their customers’ data, cannot share such data with other organizations without their customers’ consent.

Universally, all privacy-related regulations like GDPR, CCPA and the like, more or less, have one thing in common: any collection and disclosure of private customer data must be announced and disclosed to the data owner and articulated well and that the required permissions and consent must be collected by the data custodians before new uses of customer data are put in place.

Cross-Firm Verification of Personally-Identifiable Information (PII)

There are a range of cases in which making customer data verifiable for other organizations becomes a necessary tool to help minimize chances of fraud, record mismatch, compliance as well as easing validation and verification of records.

Interestingly, and inconveniently, in many of such cases, there are business processes that require such verification as part of a back-end behind-the-scene scenario that cannot involve the actual owner of the data.

Examples include a payment process in which the verification of the payee’s details may help with prevention of certain types of scams and fraud. In a payment scenario, one can’t easily make the success or failure of the payment dependent upon an action that the payee must undertake. On the other hand, the payee has already consented to providing their payment details to the payer (or at least it is assumed to be the case) and making the success or failure of the payment dependent upon a payee’s action may not be ideal. In other words, at least till now, in order to receive a payment, all what a payee needs to do is to provide their payment details to a payer without the payee having to do anything more the moment the payment is being processed. Other examples include backend credit checks, law enforcement investigations, post-crime investigations and many more.

As a result of these observations and facts, one should conclude that in cases like these, there is a need for organization-to-organization verification of private customer data without the customer’s direct involvement.

Confirmation of Payee (CoP)

“Confirmation of Payee” or “CoP” is a facility provided by a payer’s bank that makes it possible to verify the details of a payee (as provided by a payer) thru relevant means and tools.

The goal of Confirmation of Payee is to minimize chances of a class of scams like payment redirection fraud, authorized pushed payment fraud, misdirected payments, payee impersonation scams, vendor impersonation scams, invoice redirection fraud and the like.

In many payment clearing protocols, funds are routed between banks and accounts only based on account identifiers. Such protocols do not involve the checking of other details. Reasons of not including such details in such protocols include privacy and data sharing restrictions, legacy protocol definitions, low-bandwidth non-data-rich interfaces between banks and the classic notion in the banking industry that it is the payer’s responsibility to know to whom they are making a payment (as opposed to being the bank’s concern).

In many of these scams, an adversary replaces the original payee’s bank account identifier with an alternate that is under their own control (mostly a mule account) while leaving the name and other details of the payee unchanged. The payer is then encouraged to believe they are paying their intended payee unaware of the fact that funds get re-directed to the scammer in an unrecoverable fashion.

CoP can be viewed as a specific version or use-case of “Cross-Organizational Verification of Customers’ Private Data” and all the typical inconveniences applicable to that problem also apply to CoP. Given that it highly correlates with financial and banking data and financial crime and scams, there is a sense of urgency to implement it but all the inconveniences make it a hard puzzle to tackle.

Solution Options

So two organizations need to verify the details of their customers against each other’s records. What are the options?

1.Each firm to expose APIs to be directly used by other firms to verify the other organization’s customer data

Analysis:

· Necessity to seek customer consent or alternatively, to seek regulative loosening to allow cross-checking or sharing of private data

· Necessity to expose sensitive APIs with all relevant concerns (e.g. access control, security, scalability, and high availability etc…)

· Requires a centralized ‘end point lookup’ facility

· Complexity and operational costs to expose and maintain API endpoints

2. Forming a centralized trusted intermediary to be sent private data and to be asked to verify private data

Analysis:

· Necessity to seek customer consent or alternatively, to seek regulative loosening to allow cross-checking or sharing of private data

· Centralization of a massive private datasets, making it a target for future exposures and security vulnerability

· Necessity to form an inter-bank consortium which mostly requires regulative softening and state’s intervention

· Can only work jurisdictionally in a limited non-universal capacity

· High costs of making such a service available and secure

3. Each firm to use heuristics and fuzzy logic on a dataset collected from their own customers and other resources (e.g. scam reports) to guess if the other firm’s customer data is valid or not

Analysis:

· Has limited success and reliability with more cosmetic effectiveness

· May have an unacceptably-high false negative result (e.g. for cases where the dataset includes invalid fraudulent data that have been left unreported)

· Cannot cover all other relevant firms and their customers

4. Use cryptographic zero-knowledge and privacy-preserving techniques to refrain from firms having to expose APIs or share customer data despite being able to cross-verify private customer data

Analysis:

· Helps maintain 99% of current state

· No need for firms to expose APIs hence eliminating adoption costs, maintainability and complexity issues

· No need for firms to share customer data, as a result

o No need to seek customer consent

o No need for regulative intervention to soften privacy and data sharing regulations

o No need to establish a centralized trusted party hence being protected against future data breaches

o No need to establish consortiums and data sharing treaties between firms or countries

o Universality and cross-border operation

o Compliance with all privacy related regulations

Conclusion

Given the provided comparison of all the options to implement cross-firm verification of customers’ private data, it is obvious that the use of advanced zero-knowledge privacy-preservation techniques eliminates almost all the negative, expensive and complex demerit points of all other options and by far distance, outweighs any other option.

However, it is fairly obvious that while the external use of such a solution would be easy, its internal design would be a complex matter, which is why Payee-Auth.com’s solution has been reviewed by the thought leaders of cryptography in the country and its attributes and claims have been verified.

In the end, it is worth mentioning that 99% of the internal complexity of the Payee-Auth.com solution has been around how to make the data Payee-Auth.com maintains un-brute-forceable even by itself. It is fairly obvious to achieve this goal, simplistic methods like hashing or key derivation are not enough due to the fact that most private personal data have extremely low entropy.